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

From: Galen Boyer <galenboyer_at_hotpop.com>
Date: 21 Jul 2001 22:12:14 -0500
Message-ID: <un15xze7n.fsf_at_verizon.net>

On Sat, 21 Jul 2001, carl_at_db4o.com 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?

> Relational databases are no more than the persistent storage of
> flat tables.

But, the flat tables are linked together in relationships that make sure the data integrity is maintained. I think the hard thing for the relational guys (me being one of them) is that the object database guys seem to say, hey, lets design an application and then store all the objects in a database. 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.

Data about someone's credit cards and phone numbers is entirely different then whether a class implements an interface or not. One is data about the business, the other is data about the application.

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

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

>> Both kinds of database expose data, whereas true OO hides data
>> and exposes behavior.  RDBs have little or no behavior.

>
> Where is the advantage of relational databases?

Data integrity. Normalization gets rid of redundancy.

>> OODBs sometimes pretend to have behavior (methods in the
>> objects) but developers will find that as the application
>> domain grows they will feel a pressure to move that behavior
>> out of the database classes and into specific application
>> classes.
>>
>> <<<< end quote

>
> I can't see an argument against object databases, if they
> provide no less functionality than relational databases.

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

-- 
Galen Boyer
It seems to me, I remember every single thing I know.

Received on Sun Jul 22 2001 - 05:12:14 CEST