Re: S.O.D.A. database Query API - call for comments

Galen Boyer wrote:
> > Anyway: If I were to neglect triggers, stored procedures,
> > constraints and other vendor-incompatible constructs that
> > violate object business logic,
>
> Why do these violate object business logic?

Because you create multiple levels of interaction between data that are independant of eachother.

In an ideal OO system, you will find all the code that modifies an attribute of an object within the class of the object. If a value turns out to be wrong at a certain stage, you can easily debug, what set the wrong value. A wildly optimized relational system using triggers and stored procedures can be very difficult to debug. You might need many different tools and many different breakpoints to track down, how values are generated.

> The reason I don't
> like that is that I have seen to many times when an object
> designer has come to me with a database design that "makes
> perfect sense based object model" but has many flaws based on
> relational theory. I then, design a database that supports the
> object's application needs but also is sound in a relational
> sense, and then the entire application starts humming. While
> doing this exercise, I introduce different designs for the
> objects which are better than what he started with. The
> separation of the two is a good thing, no matter the extra cost
> of mapping the two divergent things together.

The point that you might want to have different representations of stored objects for different applications has been brought up quite often in this long discussion.

Object databases can very well translate objects to persist them.

A concept of "namespace friends" could allow to automatically map stored objects to multiple classes for different applications.

> > Why do VARCHARs need a fixed length? Why do you have to
> > convert objects to strings manually to communicate with the
> > database? Can't the database do the job for you? What is the
> > string back-and-forth conversion good for?
>
> You are required to talk in SQL to a relational database. Why
> must I have a compiled java class to communicate in an JVM's
> environment?

You need one starting point, a "language" right? We take the Java programming language (and C# in the near future) as our starting point, because it is required for the applications, that our product is intended for.
Using this starting point - the programming language - we try to add as little as possible additional concepts.

If you need a database that you want to interact with in SQL, then you will want a different system. In my opinion SQL is a different level of abstraction, that can be built on top of the API we will be using. SQL has no place among objects. It might be a nice tool for human interaction with the database though.

> > Why do you need to fetch IDs after inserting records, just to
> > join them to other records? Can't the database do the job for
> > you?
>
> The cardinal rule of relational databases and the #1 reason the
> relational theory is there today is that one maintains data about
> entities irrespective of changes to anything else, and then one
> maintains the relationships of those entities through stored
> keys. I like this, it is clear, it is solid, and it protects the
> integrity of the data.

You misunderstood my question.
I did not argue against the use of IDs, which might be appropriate for many applications.

I argued against the weird and ineffective mechanisms that you need to create these IDs if you use current relational databases:

- Insert one row into one table.
- Select _seq.currval from dual
- Insert the next row and use the foreign key you just fetched.

Alternatively you might use your own system to reserve a set of keys.

Object databases store objects as they come. They take care of handling IDs internally.

> > Where is the advantage of relational databases?
>
> Data integrity. Normalization gets rid of redundancy.

Why?

> Can I use your object database exactly as I would a relational
> database, and I mean with the power of Oracle, DB2, Informix,

No, but there are different "powers" that might help for certain applications.
We will be working hard to catch up with the other "power".

Without any doubt relational databases are more mature than object databases. This is *not* a problem of object database system architecture, it only reflects money and time spent into development.

Kind regards,
Carl

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