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

>> >The power of the ODBMS is that it allows performance an order of
 magnitude
>> >faster than the RDBMS.
>>
>> Since one can physically store the data indentically in an RDBMS, one can
>> achieve identical performance. No benchmark is required to comprehend
 this
>> point.
>
>You are contradicting yourself.

Nope. My position has been and remains consistent.

>At one point you say that the way object
>databases store data is bad.

I said that object databases represent data poorly. That has nothing to do with the way they actually store data. Your inability to understand the distincton is why you do not understand the first thing about databases or the importance of physical independence.

>Now you want to store it identically into an
>RDBMS.
Of course. The relational model imposes no restrictions whatsoever on the physical storage of the data. It only defines how the database represents data to the user.

>Come on, there are differences. Object databases take care of
>references between objects internally.

The relational model allows physical and/or logical pointers in the physical structure of the database, which the DBMS MUST handle internally. The relational model prohibits the DBMS from representing data to the user with those pointers or in any way other than as values in relations.

>Object databases take care of
>inheritance hierarchies internally.

As do relational databases.

>No doubt this is faster than exposing
>keys.

The performance issue is totally independent of the logical model. Since the relational model allows identical physical structure, no performance differences need exist.

>> My criticisms of the non-relational ODBMSs are directed at fundamental
 flaws
>> in their logical data models, at false assumptions in their very
 conception
>> and at widely held misconceptions. No product will ever overcome such
>flaws.
>
>This statement can not be true since you can't possibly know all future
>development.

How does any part of my statement imply or require that I do? Your product suffers from fundamental flaws in its logical data model. As you have so amply demonstrated, the very conception of your product rests on false assumptions and misconceptions. Your product will never overcome such flaws.

While your company might be able to develop a product that is not conceived on false assumptions and misconceptions, and while your company might be able to develop a product that does not suffer the same fundamental flaws in its logical data model, such a product would have to be a completely different product from the one you now sell. You would have to start again from scratch.

>> No benchmark will ever address the issue of how much effort the DBMS
>> requires of users to adapt the database to new peformance requirements.
 No
>> benchmark will ever address the cost associated with hiring teams of
 experts
>> with intimate knowledge of the DBMS's internals, which is required to
>> achieve the performance vendors achieve in benchmark tests.
>
>With this statement you imply that all vendors fake benchmarks.

No, I do not. Please do not put words in my mouth. I am quite capable of doing that myself.

I imply that vendors expend considerable resources finely tuning their submissions for benchmark measurements to give the best possible performance for each. They have a financial incentive to do so, and they would have to be complete idiots not to do so.

>This is a
>very negative view of the world.

Nope. It's just a straw man you constructed.

>> This is the same power a relational ODMBS database with proper support
 for
>> domains provides. The question becomes: Why use a non-relational ODBMS?
>
>Can your relational database (or whatever relational database without an
>add-on O-R mapper) store Java ArrayLists, HashMaps, Vectors, Arrays,
>Multi-Dimensional-Arrays, TreeMaps from scratch?
>...without any prior work to set up tables?

Sure. Why not?

>In enables a very tight integration with the programming language.

This is where the greatest flaw in non-relational object databases lies -- no concept of physical independence whatsoever.

Not only does this greatly increase implementation work, it degrades performance drastically and completely prevents the DBMS from enforcing integrity, which forces this vital task onto application programmers further increasing implementation work.

>> If all you want to do is store the state of your application for future
>> continuation, I would not suggest using a DBMS at all. I might
>> suggest you dump core to a file.
>
>How would you query the file, in this case?

If all you want to do is store the state of your application for future continuation, you don't want to query the file. Duh!

>Why would you want to write code to "dump" to the file, if a database
 engine
>can do that for you?

Database engines do not dump core to a file. (At least, not when they function correctly. ;-) )

>Why would you not want a database that allows you to get objects back from
>the file, even if your class model changes?

If I have need for a DBMS, I would want to use a relational DBMS since they do this so very well. Why would I want to give up logical and physical independence to get my objects back?

>How would you delete part of your objects?

That depends.

>> Since the application programming language is an independent issue, all
 you
>> really require is good middle-ware and proper support for domains in the
>> DBMS.
>
>I have asked you before:
>What is this middle-ware?

What is your product besides middle-ware?

>What does it cost?

I would expect the database vendor to provide it with the DBMS for the most popular languages.

>Object databases store objects without middleware.

Since relational databases are object databases, I assume you include them in the above statement. I know I include them.

On the other hand, what provides access to the objects in your database to a variety of programming languages? Such as Java, C++, SmallTalk, Eiffel etc. Surely something must resolve the minor syntactic and physical differences among them -- Voila, middleware!

>> Non-relational object databases force the task of providing the
>> equivalent of views onto application programmers working
>> outside of the DBMS.
>
>This one currently is true since all access to object databases takes place
>through objects and possible configuration of their translation.
>
>Future object database might bring along graphical tools to model
>translations and to automatically generate application code for different
>applications by clicking together object models.

This still pushes the work of providing views onto application programmers working outside of the DBMS. Who cares whether they work in a traditional programming environment or with a limited graphical tool? The non-relational DBMS does not directly provide any support for different views, while the relational DBMS does.

One cannot overestimate the importance of this. If the DBMS provides no inherent support for different logical views, it cannot provide any kind of logical independence.

This means that every schema change could require changes to every application ever written. Supporting new applications becomes prohibitively expensive. Received on Tue Jul 17 2001 - 03:50:52 CEST