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

Bob Badour wrote:
> >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. At one point you say that the way object databases store data is bad. Now you want to store it identically into an RDBMS. Come on, there are differences. Object databases take care of references between objects internally. Object databases take care of inheritance hierarchies internally. No doubt this is faster than exposing keys.

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

> 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. This is a very negative view of the world. How about a challenge? - Someone else provides a model of lets say 5 classes. - We store something between 50 and 1000 of objects of these classes and measure the time for storage.

- I implement the code with our object database.
- You implement it with whatever relational database you wish.
- We post the results here.

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

I don't think so.
This is where the power of object databases lies: In enables a very tight integration with the programming language. Not only does this minimize implementation work, it also improves performance drastically.

> >I "argue" from the position of reality.
>
> As do I.

O.K.
What is the "real" relational database product you are referring to, with your "domain" concept?

> 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? Why would you want to write code to "dump" to the file, if a database engine can do that for you?
Why would you not want a database that allows you to get objects back from the file, even if your class model changes? How would you delete part of your objects?

> If you assume SQL as the DBMS language. I don't. I would prefer a
 relational
> database language that is closer to the algebra. I would prefer a
 relational
> database language that prohibits duplicate rows, that provides adequate
> support for domains, that does not allow NULL for missing information,
 that
> properly supports updatable views etc.

This is what Jim ment with your theoretical argumentation. You talk about relational databases that do not exist.

> 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 does it cost?
Be specific as we are.

Object databases store objects without 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.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com