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

>> I have already explained ad nauseum how
>> non-relational OODBs add complexity.
>
>No, you haven't. You have explained how using object oriented languages
>creates problems with relational databases.

As I told Rico, if all you are going to do is put words in my mouth and contradict me without adding any content, you can fuck off now.

The very simple relation already provides all of the functionality of sets, bags, collections, arrays, hashes etc. These additional logical interfaces only complicate the language.

>If you take the language as given

How many managers, business analysts and shop clerks understand Java? Or ever will? Why the hell should any DBMS assume they do?

>an object
>database that stores all the concepts that the language provides does not
>*add* complexity, it simply helps the programmer to persist all the
 concepts
>that he uses.

It adds complexity to the DBMS without adding any feature to help persistence. In fact, all these needless additions to the logical data model hinder one's ability to persist objects when two or more applications must share the database.

In any case, I would not call a variety of different "collections" different concepts. I would call them different physical structures, and I see no reason to pollute the logical interface with the differences.

>> Every time the DB adds a new interface that is equivalent to a relation
 or
>> is a subset of a relation, it must add new operators, it must expand the
>> optimizer, etc. etc. etc. In the end, adding array, set, bag, hash etc.
 adds
>> complexity without any compensating benefit and causes considerable harm.
>
>Both of the statements are not true.

Of course, they are true. How does adding array, set, bag, hash etc. NOT require the addition of new operators?

>Object databases internally use
>abstraction layers to deal with the above.

If the DBMS uses relations as the abstraction layer, one really has a relational database and all of the other collection types are mere syntactic sugar in the middle-ware. If the DBMS does not use relations as the abstraction layer, it loses the ability to apply a couple thousand years of mathematical developments in the optimization process. Or has somebody recently discovered that arrays are based on a well-developed body of mathematics such as first-order predicate logic or set theory?

What useful operator identities exist for arrays that aid in optimization? In fact, what are the array operators?

Face it, your product sucks when it comes to physical independence. It provides no optimization whatsoever and requires the user to specify all access paths explicitly.

>Adding different Collection interfaces to a relational database needs work
>to be done because the user needs to write translators for all of the
>Collection classes *by himself*.

Not true. Even for SQL databases, middleware exists that provides this service. No reason exists why a relational DBMS vendor cannot provide such a thing -- especially since proper domain support would make the task just that much easier.

>Take a program that uses the above concepts as given.

You mean a program that uses the above physical constructs as a given? The single concept is "collection" as in a 1 to many relationship among objects.

>An object database
>stores all of the concepts immediately, without any necessary work for the
>programmer.

This is true, since a relational database is an object database, and since it also stores all of the concepts immediately without any extra work for users.

The questions are: What benefit do non-relational databases provide in comparison? What harm do non-relational databases cause in comparison? How does your product even qualify as a DBMS? Received on Sat Jul 14 2001 - 18:13:40 CEST