Re: Object support in the relational model??

Leandro Guimarães Faria Corsetti Dutra wrote:
> > My approach is:
> > "We have Java and we are using it. How can I persist Java objects
> > in the simplest and most efficient way possible?"
> > ...no more.
>
> That's why you end up in the common gutter that SQL has thrown us at.

Why do you criticise the approach of solving a simple task nicely and completely?

Two examples:
(1) Someone has written a parser in Java and he would like to persist the output that comes in objects of 50 different classes. Isn't it convenient, if it is possible to store the parsed graph with one single command and to query the stored objects afterwards? Would you suggest to use an "ideal" relational database instead? What would be the benefits?
(2) Someone writes a mobile Java application that is to run on a handheld with limited resources. By using a database engine that is written in Java and that directly understands objects and interacts with them, the application is much faster and much more efficient. Do you suggest to wait for the "ideal" relational database and for mobile systems with 250 MB of RAM before going productive?

I provide a practical solution for the above two examples and please correct me if I am wrong and name the alternative: I am pretty sure, it is the very best one available. What have I done wrong?

You choose the word "gutter" for SQL, but why?

How about providing a practical and production-ready replacement for SQL?
This is what I do!
You don't!

It is very easy to sit back and to laugh about the theoretical flaws in other peoples work without having to think about a *working* replacement. Java is flawed to a certain degree but if you want to make a living from selling software products, what are the choices but to use it?

I am trying to produce the best product *for limited usecases* with the best knowledge that I have. Why do you think that you are in a position to look down on me?
...and you too Bob Badour?

> BTW, what do you do with the end-user?

It's up to application programmers to provide end-user products, right? I do think about the end-user by providing the application programmer with more ease to store his objects so he has more time to build a nice user interface.

> By thinking about programming
> only you limit yourself to one application per database

Noone prevents you from mapping objects to objects, to allow reuse in multiple applications. Noone prevents you from creating "object views".

> > No worries about theories, no worries about separating methods
> > from data, no worries about what others are doing or what other
> > "highly educated" people are saying.
> > ...people that produce tons of paper that are never used for
> > anything productive in practice.
>
> So you deny that the relational model, produced by one such people --
> EF 'Ted' Codd -- has any relevance? Where have you been hiding in the
> last twenty years, when SQL, even if a extremely flawed implementation
> of the relational model and ultimately a failure, has proved its worth
> over every other approach to DBMS?

The SQL dialect implemented in the successful database products fails to store objects nicely, since it does not provide support for inheritance.

SQL forces you to write tons of code to map each individual object field to a column in the database. (I have heard enough of this "objects map to domains"-nonsense, since it has no relevance in practice because not a single successful product provides a usable implementation that takes the work away from the programmer.) There are developers that are tired of writing this brittle mapping code that breaks, whenever you modify classes or tables and some of them improve their productivity by using object databases.

> BTW, how can you create a logical model without a data model? If you
> are restricted to ERD, which poor models you are bound to create.

You can use classes (just for you: without methods) to represent the data model.

> > is the easiest to understand since it implicitely describes
> > itself completely.
>
> Only for DBMS programmers. What about DBAs, application programmers
> and end users? All of these want the logical model, not the physical
> one.

You can use classes (just for you: with methods) to represent the logical model.

You can use classes (just for you: without methods) to represent the physical model.

> You see, each OODB must be built from scratch on top of a
> DBMS-construction kit, with minute attention paid to physical details.
> Compare that with the logical model that can be implemented in a
> RDBMS, and the physical details changed behind the scenes without
> compromising the coherence of the user schema.

I see.

Kind regards,
Carl

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