Relationship Between Oo And Databases

What is the proper relationship between ObjectOrientedProgramming and databases? It seems a fuzzy and contentious topic.

Databases provide several services, such as persistence, query languages, multi-user contention management, NounModeling, and others. Some only use databases for persistence in their application. Is this a waste of existing services already available? Why recreate them again in the app? Is having objects with arrays of related or contained classes "reinventing DB indexing"? Is echoing the schema in application code a violation of OnceAndOnlyOnce? What is the ideal relationship between the two and what is the best practical one?

Is echoing the schema in application code a violation of OnceAndOnlyOnce?

I believe it is a bad idea to echo the database schema in the application code, especially if you have multiple applications. Database tables are defined based on data relationships, while user interfaces are defined based on the chronology of data entry. In my opinion, the worst user interfaces I have seen are the ones that directly present the database schema to the user. I am not sure, however, that this implies that database schemas should be be updated to reflect changes in the user interface. Rather, there should be a mapping between the two representations.

There is a gray-area in here where some claim their class designs are creating a "local view" for something. IOW, it is not schema-echoing, but view creation. The problem I have is that often it is simpler to just use a query to adapt the view rather than build class structures. Queries tend to be more local, while classes rather "global", causing a bunch of confusing adapter classes sitting around naked in the class space. What is needed perhaps is nested classes, or at least more use of dynamic structures.

[Class design should be driven by the needs of the application. One should not avoid a class design just because it duplicates a table schema.]

OO and relational databases (which, for the sake of argument, I'll assume to be the kind of databases under discussion here) address rather orthogonal ways of looking at data. One of the strengths of relational comes from the ease with which queries can be used to gather collections of related data in different contexts and with different criteria -- creating views, as mentioned above. There are no clear correspondences to analogous functionality in object oriented models.

Relational applications are harmed by data hiding; all data in the database should be exposed in order to facilitate flexible querying (modulo security considerations). OO models, on the other hand, are about hiding data and controlling access. In this sense, the two models seem almost opposed. Trying to model the entire database as objects would seem to be a wrong-headed approach.

However, there is no particular reason that object values cannot be stored as values in databases. From the point of view of the database, they would appear to be atomic values. If they support testing for equality and ordering, they could participate in queries as readily as a number or string.

On the other hand, we often find that large portions of an application are concerned with manipulating a few business classes. It is often convenient to design such independently from the database, load them with data gathered from the database, and scatter the data back into the database when the changes should be saved.

This provides an OO interface to business objects that are used heavily, providing a better fit for programming in an OO language. These business objects often correspond to the major entities of an entity-relationship model of the database. (But remember that such entities aren't directly represented in a relational database - they serve merely as a guideline in structuring schema, and as a tool for gathering requirements. ER diagrams are not rigorous models in the same sense as relational schemas.) Such 'business objects' cannot serve as a replacement for an interface to a relational database's query functionality, however; they are not flexible enough for that.

See also TheThirdManifesto, although most of the comments on it here on the wiki are not very complimentary -- possibly because people haven't studied the book as thoroughly as the topic requires.

-- DanMuller

If the database is the primary repository, then no quantity of OO classes can ever truly hide or wrap it. See GateKeeper.

Why is it more convenient [to design the objects separately from the database]? If the existing schema is not sufficient, then perhaps it is either not designed properly, or you can use "cataloged views" to provide better viewpoints. (Although views tend to be read-only.) I guess I would have to see some examples of failure using the database directly (with views) or examples of significant improvement by putting class wrappers/adaptors around them.

I was not advocating hiding the database behind OO classes. Quite the contrary. I advocate not hiding the database, and using objects only as a convenient place in which to hold data when it is being manipulated by an application -- the objects are an adjunct of the application and tailored to it. For many applications, depending on the language and database APIs available, such objects might not be helpful at all.

Of course you would use customized views of a database to facilitate loading and saving of such objects, that's only prudent. The problem with using objects to wrap databases is that there are many, many possible views of a relational database, and non-trivial applications will in fact use many different views. Defining different objects to encapsulate each view is onerous and unnecessary.

I looked a bit at GateKeeper. With respect to relational database access, I don't think it's really applicable. Proper relational database systems let you specify data constraints declaratively, which is a paradigm that is far better suited to data management than procedurally-based OO methods. It is much simpler to understand and maintain. (The fact that some database management systems are limited in their ability to declare such constraints is lamentable, but is not a shortcoming of relational database theory.)

-- DanMuller

You wrote:

: Database tables are defined based on data relationships, while user interfaces are defined based on the chronology of data entry. In my opinion, the worst user interfaces I have seen are the ones that directly present the database schema to the user. I am not sure, however, that this implies that database schemas should be be updated to reflect changes in the user interface. Rather, there should be a mapping between the two representations.

Now, what brought me to earth with a thump (I was reading at high speed) was the last phrase in the first sentence, i.e. "user interfaces are defined based on the chronology of data entry". At second or maybe third reading it came clear to me what you meant, but it took that process; perhaps that phrase is very usual within your domain?

What I intended by the phrase "chronology of data entry" was that users often collect and enter different pieces of data at different times. This is also referred to as the work flow. The user interface presented needs to reflect the user's workflow and allow the user to enter all of the data collected at one time on one or a small number of screens. Users dislike having to jump between multiple screens to enter data.

-- BenTremblay 25DEC02

As you no doubt intended, I'm not sure what your revelation is -- but perhaps you might be interested in reading about TableOrientedProgramming? -- DanMuller

Thanks Dan (not quite what I was pondering, but darned interesting).

Regarding the relationship between DB schema's and user interfaces, what I have found in practice is that there should be an intermediate schema/structure to map between the two. I like to use something similar to DataDictionary(s) (perhaps "field dictionary" would be a better name) for this purpose. It would be interesting to study some actual case histories where the schema and the UI don't match up to see if there are any consistent patterns. The patterns may highlight bad schema design, bad UI design, or just that there are times they don't match up. Also, I am curious why the word "chronology" is being used. Column ordering is not defined in "strict" relational theory. (Whether that is good or bad is another discussion.)

Is there similar issues between the OO class structures and UI structures?

Returning to clean up here [see deletions above] one aspect of Dan's material above strikes me as particularly salient, i.e. the relationship of UI to (as he formulates it) the database schema; I can rotate my conceptualization to make these two orthogonal. Is the schema capturing anything about intention? I strongly hope not, though expedition and "enablement" is of course central. And here's why I'm bothering you all: are we chasing after the user to serve him/her hand and foot? Or are we de-scribing the actuality using a language that allows for manipulation and inquiry?

The physicist says 2+2 depends on universal law-like behaviour; the philosopher might point out that 2+2 is historically contextualized and culture bound; the account asks what you would like it to mean. I'll serve the first two; of the last I have nothing civil to say.

Do taxonomies come to work here? Does ontology come into play? -- BenTremblay

In my opinion schemas are primarily to capture the "quantity of relationships" (1-to-many, many-to-many, etc.) If you get such right and factor out duplication, then you are pretty close to good normalization. User interfaces also often happen to divide on similar lines as the entity divisions, but not perfectly aligned. It is one of those situations where things are about 80 percent similar, but you cannot directly couple them because the 20 percent would mess everything up. Is there a name for almost-ness ruining simplification attempts? It is a common problem in my observation. Maybe ExceptionsWagTheDog??

No, schemas are not specifically about capturing relationships. Relations (tables) in relational databases capture a representation of facts that are of interest to the users of a database -- a relation is an assertion of facts. Data constraints, which are part of a logical schema, may require certain relationships, but there may be many relationships that can be discovered without being explicitly designed into a schema. Normalization is about organizing the facts in ways that are not redundant or unnecessarily coupled.

I kind of meant the process of designing the schemas. I suppose there are multiple cognitive roads to the same or similar destinations though.

UI design may often mirror portions of the database; that shouldn't be surprising. However, it need not, and in fact often different parts of a UI will show the same facts organized in different ways, so the UI can't always mimic the database schema. In relational databases, views (queries) can organize the data in ways appropriate for each part of the program. I would say that, yes, generally, UI and schema design are orthogonal, though the design of each certainly tends to inform and influence the design of the other.

I think the TableOrientedProgramming ideas stem more from the notion that data describing the UI itself, like most data, can be organized into relational database form in a fairly straightforward fashion. Being able to treat executable code as first-class data in relations certainly opens up some intriguing possibilities.

OOP arose largely in connection with event-driven UI programming, as I understand it, and fits it well. Thus it might make sense to gather database data into objects for convenience of display and editing. But data constraints belong in the database system itself, where they're most conveniently defined (declaratively), maintained, and universally enforced; it would be a mistake to move them up to wrapper objects.

-- DanMuller

I don't see why TableOrientedProgramming cannot also be applied to event-handling. If you have hundreds of events, then organizing and managing them in tables may be a boon. After all, we don't want all the Employee records in code also. I would go into more detail here, but I think it may be off topic. Perhaps EventDrivenProgrammingTechniques? or something.

I agree. I think that table-oriented programming sounds very promising for many classes of programming problems. I think I would include TOP concepts in my IdealProgrammingLanguage.

I think databases are counter to the very concept of OO (as I interpret OO). In OO a class would "own" the state (data). Any communication or action on that state must go through that owning classes per encapsulation. If other applications wish to talk to such data, they go through the owning class, maybe via SOAP or something. As far as persistence, OO really wants bubble memory. The current issues of persistence are caused by the current state of hardware and OS designs that make a heavy distinction between disk and RAM. If you rid that distinction, then battles over persistence techniques would go away. The OO code then becomes the "database". I am not saying whether this would be a good thing or not. I am only saying that under "pure" OO, a databases is nonsense. People who don't like NavigationalDatabase-like structures may not like this approach.

Here are the relationships between OO and databases:

Applications written in OO programming languages using OO programming techniques can be clients of databases.
Databases can be written in OO programming languages using OO programming techniques.

The confusion on the rest of this page (and many other pages) come from forgetting that databases are not programming languages. You can't write an app in a database without some sort of programming language on top of it. Applications aren't just data. They are behavior too.

I think those viewpoints have been brought up elsewhere, but I still don't see the significance of them. What a database is written in is almost completely moot from the DB user's perspective. Other related issues are under AreOoAndRelationalOrthogonalDiscussion. Maybe these topics should be merged. You seem too focused on the low-level implementation mechanics rather than the design philosophies. ANY TuringComplete language or paradigm can implement a database.

The significance is that it answers the questions given at the top of this page:

What is the ideal relationship between the two and what is the best practical one?

The relationship between OO and databases is small and well defined. OO (in the title of this page) seems to mean a set of programming languages and techniques for writing computer programs. Databases are computer programs. Programmers use OO programming languages and techniques because they provide a useful way to organize instructions. Programmers use databases because they provide a useful way to organize data. Sometimes programmers use OO languages and techniques to write programs that use databases, based on the needs and resources of the customer.

Databases are not "counter to the very concept of OO", as argued above, any more than printers, disk drives, terminal, pipelined computation engines or any other service a program written in an OO programming language and/or using OO techniques might use.

Databases and OO fight over who gets to wrap the state. They cannot both do it (without duplication). If you let the database handle most of the state, then OO has less to do and starts looking more like procedural. It is like a race-car driver on the bus.

You're describing a specific situation where there is little demand for new behavior. If there are existing applications that provide the behavior you need, use them. If you need to develop new applications you'll need some sort of programming language. Databases are not programming languages. OO programming languages are one good choice.

I never said that the database was to provide the whole party. That is why we have subroutines and modules. The biggest differences between OO and procedural is in how state is wrapped and carried. The database does what objects would normally do for the most part. Objects that don't carry state are generally wasteful and bloated.

You're describing a specific situation where a database can be used to hold every variable in a program. I've never run into that situation. Where have you seen it?

No. Simple variables will be simple variables probably under both approaches. It is when we start dealing with more complex structures or relationships that the difference comes into play.

But when are all variables (simple or complex) stored in a database instead of local memory? What programs work this way?

Much of the discussion on this page appears to assume that "code" and "data" are different. I suggest that our experience teaches us that they are not. When we admit that code and data are two ways of viewing the same representation (whether that representation is stored in a "database" or a "program"), we discover that the distinction of this page dissolves.

More specifically, some of the content of a relational database can be information that is sometimes executed - after all, source code repositories do this all the time. There are no theoretical limits on the ability of such a database to reflectively describe itself - some of the early ObjectOrientedDatabase approaches were premised on just this approach.

Once we admit the camel's nose into the tent -- and admit that the behavior of the database can change based on updates to the database -- then I suggest that it becomes clear that the RelationshipBetweenOoAndDatabases is completely arbitrary.

In short -- "Object Oriented" appears separate from "Database" because we chose to design existing programs and databases that way. We are free to make other choices whenever we like.

-- TomStambaugh

Just because the content of a relational database can be executed doesn't mean the structure of data in the database has any impact on the structure of data in the executing application. That's like saying there's some connection between tree structure and OO when OO code lives in traditional directory structured flat files. Visual Age keeps source code in a database but the exact same source code can be kept in flat files without changing its behavior. -- EricHodges

I don't understand your response. Can you try different words for the same idea? I don't see any connection between what I wrote and your reply.

You argue that the place code is stored has some impact on how that code models data:

"More specifically, some of the content of a relational database can be information that is sometimes executed -- after all, source code repositories do this all the time."

I (EricHodges) argue that the way code is stored has nothing to do with the data structures used by that code. Relational tables are data structures. Programs can use them (and others) no matter where their source code lives.

I argue further that the behavior of a traditional database does not change based on the content of the database. Some databases add stored procedures, but these can be viewed as programs run by the database. The database service itself does not change.

TomStambaugh responds: Now I understand my miscommunication with the original responder. I did not mean that the place where the code is stored matters. I meant that the assumption that "storage" and "execution" have to be different is arbitrary. More specifically, I mean that a database could be (and has been) designed so that its own executable code is read from within itself. The limitations of SQL probably preclude describing this in SQL, but SQL is not the only way to create, read, update, or delete relational data. I thus argue that databases that are designed to be passive data stores are (duh) passive datastores. The observation that our current relational databases are passive does not mean that there is some fundamental theoretical barrier to creating a system that is both Object-Oriented and a database.

Now I'm lost. Storage and execution are different. There is nothing arbitrary about that. If a database executes stored procedures it does so in addition to its storage services. Stored procedures are just one place executable code can live.

There is nothing that prevents me from writing a database such that it executes code that is stored within itself. When I say that the choice is "arbitrary", I mean that it is perfectly possible to implement such a database -- and such databases have already been written (granted in non-commercial settings).

But what does that database imply about the relationship between OO programming languages & techniques and databases? The code that the database executes would still fit some programming language paradigm (OO, functional, declarative, etc.). The way that code interacts with data in the database would be no different that the way a Java program fetches result sets from an RDBMS, would it?

It implies, to me, that a "database" is a particular application of a programming language. It further implies, to me, that the language environments that are interesting to me (Lisp and Smalltalk in particular, but also including Scheme, Forth, PostScript, Self, and lots of "research" languages) are fully capable of providing all of the services mentioned above. It implies to me that a "database" is a subsystem like any other subsystem. As such, the boundaries and capabilities of a database, like any other subsystem, are the result of intentional or unintentional design decisions. This is why I assert that any attempt to describe an objective, external differentiation between "OO" and "Databases" is futile.

Agreed. Databases are a convenient way to manage data. OO programming languages are a convenient way to manage instructions. Each is designed to meet distinct needs. This page isn't about differentiating them, but the relationship between them.

I disagree with that characterization of OO. OO in general is about wrapping state. In this sense it starts to overlap with what databases try to do. True, all programming tecniques deal with state, but when we get into complex structures, then OO and databases fight over who gets to own and/or wrap them. More on this in AreOoAndRelationalOrthogonalDiscussion -- AnonymousDonor

OO programming languages and techniques are not "about wrapping state". Data structures expressed in OO languages are no more or less complex than data structures expressed in procedural languages. If OO languages and techniques are "about" anything, it's about indicating in code the association between behavior and data.

I suppose this pivots on the style of one's favorite OO methodology. In my opinion, OO philosophy often over-couples behavior and data. I don't know if this is because OO fans perceive the world differently than I do, or because OO training pushes the idea that they should be tightly bound. -- AnonymousDonor

Over couples compared to what? Procedural programming languages? What languages would you rather see used?

In my opinion both procedural and OO programming languages couple data and behavior. OO languages add support for encapsulation. Instead of passing every piece of data to every method, some data is kept in the object. This reduces code complexity.

How about an example? Trivial data can be put in something like a dictionary array. More complex "state" is in the database, not passed around as a bunch of parameters.

Example: an icosahedral map for a single player game.

Sorry, that is outside of my domain of experience. Databases for game implementation is still a new area. How about something related to the CampusExample.

The problem domain doesn't matter. The game map doesn't require the added expense (licensing or performance) of using a database.

This is perhaps a topic for WhenAreDatabasesNotAppropriate. There are open-source and NimbleDatabases.

The nimblest of databases is overkill for many data structures. Everything is not a nail, hammer man.

Back in my dBase days, I almost never used arrays because tables were so easy to create, use, and inspect in that tool. (I am not saying it was a perfect tool, but it sure made table-related stuff a snap. It was pseudo-relational, BTW.) I still think this sub-discussion belongs in WhenAreDatabasesNotAppropriate.

Re: Much of the discussion on this page appears to assume that "code" and "data" are different. I suggest that our experience teaches us that they are not. When we admit that code and data are two ways of viewing the same representation....

I agree that they are generally interchangeable. (There are some existing topics on this that I will include when I find them again.) But, OO usually has a NavigationalDatabase-like structure to it. Most production databases are relational. TablesAndObjectsAreTooDifferent to be merely different views of the same thing. Relational imposes the "table shape" that OO is not restricted to. The upside of this restriction is that one can do relational "math". Perhaps with an OODBMS (a form of NavigationalDatabase), the distinction could be made transparent between OOP code and data, but relational and OO are different animals. I don't see any easy way around the inherent difference between OO structures and relational structures, even if the boundaries between code and data are removed. It is an area that needs more research and pondering.

How can anyone assert that code and data are interchangeable? Is it possible to replace a program, say a word processor, with a database? Is it possible to replace a data store, say your last 10 years of income tax filings, with a program? Code manipulates data; both are necessary, but different.

It is in part a matter of your point of view. In some sense, machine instructions are data that are read and acted on by a CPU. At a higher level, patterns in code can sometimes be replaced by (usually much less) table-driven code and data that describes what is to be done. Similarly, code can often be stored, retrieved, and arranged like atomic units of data (they appear as function pointers, closures, or blocks in some higher-level languages). In a few cases, most notably in Lisp, program code can be treated as data at a much more literal level, by actually manipulating data that represents code in great detail, and then executing it. (Lisp's macros work this way, for instance.) At a lower level, you can see the same thing in programs that create machine instructions, store them, and execute them. (Traditional compilers and linkers very naturally treat code as data.) Really, the two are quite a bit more interchangeable than they appear at first glance. -- DanMuller

Agreed that CodeIsData. But that doesn't mean that the relational model is a suitable model for code. I've tried to construct a pure TableOrientedProgramming language, where code is "tables all the way down" in the same sense that SmallTalk is "objects all the way down". It just doesn't work. I even tried bringing a bit of GroupTheory? into it, because groups are the mathematics of how sets combine and transform into one another, and the RelationalAlgebra is all based on SetTheory.

The fundamental problem seems to be that tables are a way of grouping homogeneous data, while objects/functions/code is a means of grouping potentially heterogenous data. The tuples in a relation all share structure; they all have to have the same header, same fields, same types, etc. The operands in an expression have no such guarantee; they're not even guaranteed to have closure! For some functions, like toString() or other conversion operators, this would defeat the point: you can't have closure when the source and destination, by definition, are of different types.

Even things like arithmetic become very difficult to represent with the RelationalAlgebra (contrast with the LambdaCalculus, where there's a fairly simple Peano scheme to represent them). I suppose I could've defined a "virtual multiplication table", like how Int in HaskellLanguage is defined as syntactic sugar for -2billion | -2billion+1 | -2billion+2 ... | 2billion. Arithmetic operations would then be defined on a table of <operand1, operand2, result> with project<result, select<operand1 = lhs && operand2 = rhs, +>>. Function composition would be the same as a join; you join the result of one operation with the table for the next operation.

But even if you work out the efficiency issues (which aren't that big a deal; you can always open-code the machine primitives), it still wasn't something that I wanted to work with. You end up with a massive AbstractionInversion, trying to use tables where simple binops do fine. Lambda calculus and OOP work fine all the way down to the micro-level; look at HaskellLanguage or SmallTalk for existence proofs. Relational, however, seems to become enormously clumsy as the number of entities that share a given property shrinks to small numbers.

I'm not implying that tables are useless. I like TableOrientedProgramming, and I'm certainly planning to include TOP features in the programming language I'm developing. I'd love to create something equivalent to SmallTalk or Lisp in the relational domain, simply because the relational model has so much power, but it seems damned hard. SmallTalk frames everything in terms of "object message", Lisp in terms of "(func arg1 arg2)" and "(lambda (arg1) (func arg1 closure...)". The RelationalAlgebra, however, has 6 fundamental operators, none of which seems general enough to model ordinary programming language concepts.

I'm going to pick up TheThirdManifesto on my way home and see what DateAndDarwen have come up with (I've already read AnIntroductionToDatabaseSystems). From the online samples I read, it seems like they augment tables with procedural/pseudo-OO constructs, so it's not really pure TOP.

Oh, and OO isn't like NavigationalDatabases at all, like TopMind continuously claims. If you have to "navigate" between objects, you've got massive LawOfDemeter violations going on. A Java programmer might write such code, because most Java programmers are really reformed C programmers trying real hard to like OO. But you'd never see it from a Smalltalker.

-- JonathanTang

You'll probably find TheThirdManifesto pretty interesting. However, they make no pretenses of replacing procedural elements of coding with relational elements -- the TutorialD language contains all the usual procedural stuff. They do talk about function composition as you describe, but only as a technique for describing relational extension in the algebra.

I'm not surprised that you found it difficult to express programs completely in a relational style - that sounds quite difficult. There's probably a lot of interesting middle ground to be explored, though. It would be quite interesting to be able to store callable elements (closures, lambdas) in tables. -- DanMuller

I'm definitely shooting for that in my IdealProgrammingLanguage, plus being able to apply HigherOrderFunctions to relations (so you could map, fold, or filter over a relation). Actually, I'm finding that many relational operators have analogues in FunctionalProgramming. Select, for example, is nothing but a filter over the relation. Group by becomes fold (or in Lisp/Python parlance, reduce). Project is a map of a partial-application over the relation, undefining part of the domain (I'm modeling tuples as functions from symbols to values, the same as records/scopes/packages/objects, and I'm modeling relations as abstract data types that implement the collection interface). I think a CrossProduct is the same as a ListComprehension, which is just a map over a map over collection. Rename is surprisingly not trivial--I think that the GeneralizedReference mechanism I've come up with can handle it though. I could swear I'm missing an operator or two, but can't remember it.

I like the conceptual simplicity that comes from unifying paradigms all the way down. SmallTalk, to me, is a beautiful language - it's objects all the way down. Lisp and Haskell are beautiful languages - they're functions all the way down. I don't get the same satisfaction out of Java or Python or TutorialDee, because they need to introduce other constructs to get useful work done. While I'll use such a language if the pragmatics demand it, I'd much rather see some simple metaphor extended all the way up. I'd love to see OO and relational unified, but that's a very, very difficult problem.

-- JonathanTang

(Perhaps move this to IdealProgrammingLanguage?) Common Lisp and Oz changed my thinking on this a bit. Both build up multi-paradigm programming vocabularies from a small set of conceptual primitives -- Oz perhaps more explicitly so than Lisp. Although conceptually relatively simple, one still ends up with a rich vocabulary that supports quite different modes of expression. I haven't programmed in SmallTalk, but objects don't seem fundamental enough to me to serve as the organizing principle -- it leaves you with a language that does objects well, but is awkward for other paradigms. I suspect that the same might be said of relational theory -- it concerns itself primarily with collections of things, and has deliberately little to say about the nature of atomic attribute values that make up those collections.

Part of what DateAndDarwen are doing is to circumscribe the properties of attribute values in a way that is compatible with both relational theory and with typical programming paradigms, without the limitations that typical RDBMS implementations' rudimentary set of field types impose. Many people on the wiki rail against their work as belittling or downplaying object oriented programming. In contrast, I see it as trying to find ways of bringing the two paradigms together in our programming environments.

-- DanMuller

Hang on, the 'Database' is an object itself. It is not a part of a language in its pure sense. The database service to store state, provide methods in the form of stored procedure or some other access metaphor in order to reference its state, however the database essentially is simply an object from which other objects be it classes will interact with. The medium of differentiation is the domain of the interface that the DB exposes and the semantics of mapping and control, which could itself manifest as another object that provides translational services.

Think of two English and a Spanish people. The Spanish person writes down dictations form the English person. There is an interpreter in the middle there.

What is the database in this scenario? The book? Or the Spanish guy.

I don’t see where OO ends and the DB begins.

Ah, but isn't that one of the problems with the term "object"? Anything can be an object. Even a program written in C is an object, isn't it? Really, I don't see the point you're trying to make.

They are perhaps equivalent views of the same thing. Most EverythingIsa's work. It is a matter of human preference.

A good many of the questions and debates on newsgroup comp.object revolve around OO's relationship with RDBMS. It is an area that needs to be better addressed one way or another in order to bring maturity to OO (if possible). Regardless of whether objects are "good" or not, there is a dearth of good information about how the two can be and should be related to each other. There are various "patterns" and suggestions floating around, but few guides on finding and comparing the pro's and con's of each. -- top