Re: Clean Object Class Design -- What is it?

Boys, boys. When will you two play nicely together? Honestly, sometimes I think you two *try* to misunderstand one another.

"Bob Badour" <bbadour_at_golden.net> wrote in message news:cd3b3cf.0107231703.54d0a6b9_at_posting.google.com...
> > > If the OID (or some other pointer) is not visible to the user, how
> > > could the test ever fail when the object values are the same?
> >
> > ???
> >
> > The test can very well fail:
> >
> > Person bob1 = new Person("Bob");
> > Person bob2 = new Person("Bob");
> > if(bob1 == bob2)
> > // will return false
> >
> >
> > A similar example comparing the results of two queries:
> >
> > ObjectSet results = db.get(new Person("Bob"));
> > while(results.hasNext()){
> > Person bob1 = (Person)results.next();
> > ObjectSet compare =
> > db.get(new Person("Bob Badour"));
> > while(compare.hasNext()){
> > Person bob2 = (Person)compare.next();
> > if(bob1 != bob2){
> > System.out.println("Not all Bobs are Badour.");
> > }
> > }
> > }
> >
> > Where are OIDs or pointers in the above example?

>
> On either side of the '==' and '!=' operators, which clearly operate
> on pointers.
>
>

Still, it would be nice if you would answer his question and tell us with which object databases you have experience.

> > Some of the false statements that you have posted:
> > False 1: Relational databases are object databases.

>
> You have not explained why it is false, while I have repeatedly
> explained why it is true:

I'd like you to explore this a little more. If I understand the concept behind domains, they allow you to aggregate basic data types into an entity that can be manipulated as a whole. That's nice, but it's not much more than a C struct. Can an element of a domain be an n-ary relationship to another domain?

In an object-oriented world, an object can have members that are plain-ole-data (POD), other objects, references to other objects, or no data members at all. Can a domain do all this?

If not, then it seems we are forced into a hybrid definition where some (simple) kinds of objects can be represented as domains and other more complex objects must be represented as table rows or something else. In fact, it occurs to me as I look at Date's classic example definition of a relation that the relation definition looks all the world like a (simple) class schema.

Now you've stated emphatically that the row is not the object, but it's not clear that your distinction can hold.

> It is true because relational domains are object classes, tuples are
> sets of object values, relation values are sets of sets of object
> values and relation variables are sets of sets of object variables.

And in an object database, sets of object values are/can be objects and sets of sets of object variables are/can be object. That distinction seems to be a little lost in your definition.

> > False 2: Object databases expose pointers.

>
> Again, you have not explained why it is false.
>
> Your own example above demonstrates that the non-relation object
> databases do expose pointers. Both the '==' and '!=' operators in your
> example operate on pointers.

Only if you say so. Remember that Carl is writing an explicitly Java database and Java has no pointers (or everthing is a pointer, I can never figure out which). The test for equality that Carl cited is much more likely to invoke the operator== method of his class than to do a simple pointer compare.

I will grant you, in the purist (not purest) sense that the notion of object identity is almost always implemented in terms of some reference. So while an OID is conceptually a pointer, so is the row-id generated by commercial RDBMSs. It's just that the OID is more natural in an object-oriented envirionment where everyone is used to dealing with references to things, where row-id is nothing but an ugly hack.

> If the only thing that distinguishes two object variables is an OID,
> the user could never distinguish them unless the DBMS does expose the
> OID.

Only if the user relies on the DBMS to do all his work. While I am sympathetic to your affinity for the mathematical rigor of set theory and the relational model, there ARE a useful class of problems that must be solved using iteration (with today's products). While I am iterating over a result set, the OID is not exposed to me; it is usually encapsulated in some other mechanism that makes it look to my programming language (not me, the user) like a pointer. If that's too subtle a distinction for you, I'm sorry, but that's where you and Carl fundamentally disagree on this point.

> > False 3: Object databases do not have performance advantages.

>
> Again, you have not explained why my statement is false. I have
> repeatedly explained why it is true:
>
> The relational model determines only how the DBMS represents data to
> the user and not how the DBMS stores the data. Since the DBMS can
> store the data identically to a non-relation ODBMS, it can achieve
> equivalent performance.

Your statement is false because there is no commercially available database today that can achieve the real-world performance of (most, many, all?) object databases. I accept your theoretical position that the relational THEORY allows for a physical data representation that matches the implementation of object databases, but such theory is not implemented. In fact, what you are in essence arguing for, while admitting the performance benefit of the object database representation, is a layer on top of an object database that transforms the "natural" object structure into your pure relational model. I have no doubt this could be done, but it is an irrefutable fact of computer science that every layer costs performance.

Your other arguments about the flexibility of the relational model, especially if true physical independence is achieved are valid, but I don't see how they can possibly address performance.

> > False 4: Object databases add complexity in handling objects.

>
> I have never made the above statement. Please do not put words in my
> mouth. I am quite capable of doing that on my own.
>
> I have claimed that non-relational ODBMS add complexity to the logical
> interface to objects, and I have repeatedly explained why and how they
> add this complexity.

I guess I don't get the distinction. Isn't adding complexity to the logical interface to objects the same as adding complexity to objects?

If objects in a database can be referenced/manipulated/"handled" natively in the programming environment, then I don't see the added complexity. In fact, when one must shift paradigms between "database objects" and "non-database objects", that's where I see complexity added.

What I think Carl takes as a given and I don't think you accept at all is the target audience of the database. I think most object databases are intended to be used by programmers. You seem to want to insist that the target audience of a database is a human. I tend to side with Carl, because every database I've used (relational or object) was hidden behind the code I was writing. Received on Tue Jul 24 2001 - 03:46:01 CEST