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.

I think I understand Carl extremely well. How do I not?

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

First, explain how it would have any relevance to any of my arguments.

>> > 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?

Does a C struct define the operators that apply to it as a domain does?

>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?

Yes, it can.

>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.

Since your initial assumption is false, I won't bother to respond to this.

>> 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 sets
>of sets of object variables are/can be object. That distinction seems to be
>a little lost in your definition.

In my definition, a domain can have relation-valued attributes. Do you have a relevant point?

>> > 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).

Everything is a pointer.

>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.

Well, if the operator== method looks only at the values of the objects' attributes, it will treat both "Bob Badour"s as the same object. It will only establish identity among the objects if observes the pointers.

>so is the row-id generated by commercial
>RDBMSs.

Which violate 1NF and which make commercial SQL databases non-relational. As do duplicate rows etc. Do you have a relevant point?

>It's just that the OID is more natural in an object-oriented

You have not addressed any of my prior arguments (nor three decades of prior arguments from relational proponents) regarding the problems of exposed pointers and forced navigation.

>> 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).

Are you talking about application programming logic or database management here? If you are talking about application programming logic, then you are not addressing the issues I have raised regarding database management. If you are talking about database management, then I must point out that you are making an extraordinary claim requiring extraordinary proof, and I disagree with your statement.

>> > 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.

Again, you are making an extraordinary claim here requiring extraordinary proof. You have not given any.

>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.

My position is not strictly theoretical; it has significant empirical backing.

That said: the full relational model won't ever get implemented until the market willingly sheds its misconceptions and ignorance.

>In
>fact, what you are in essence arguing for, while admitting the performance
>benefit of the object database representation,

I have made no such admission. Please do not put words in my mouth. I am quite capable of doing that myself.

>is a layer on top of an
>object database that transforms the "natural" object structure into your
>pure relational model.

Bullshit. Show me where I have ever made any statement even approximating the above.

>> > 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?

Relational databases are object database and they add no unecessary complexity to the logical interface to objects.

>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.

I think anything claiming to be a DBMS must intend use by all users -- programmers and non-programmers alike. Any so-called DBMS that inherently excludes a large portion of the user community does not perform the basic function of database management.

>You seem to want to insist that the
>target audience of a database is a human.

The target audience of a database is a database user whether human or machine.

>I tend to side with Carl, because
>every database I've used (relational or object) was hidden behind the code
 I
>was writing.

Every database I've used was exposed directly to me, to my colleagues and to other users of the DBMS. If you intentionally limit use of your databases to programmers, I expect you to observe that only programmers use your databases. I just question what one can conclude from the observation. Received on Sat Aug 04 2001 - 13:20:48 CDT