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

On Sun, 22 Jul 2001, carl_at_db4o.com wrote:

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

But, your argument hasn't really shown how these stored objects violate any object principle, unless object principles are built around simplification of debugging, but yes, code on the database violates OO design, that is why I code them as basically stored objects that get called by object methods but rarely call each other.

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

That wasn't the point. My point was that taking a purely relational view of the data pokes many holes in a supposedly "perfect" object model.

> Object databases can very well translate objects to persist
> them.

Then, persist them into a database designed by a relational guy, not automated by an OO mapper. I'm all for OODB's to act as cache for the application. Sounds like a really great use of them.

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

Well, objects need to get used to the fact that they better understand how to interact with SQL, cause, that isn't going to change. A client's data is king. Number one, no ifs ands or buts. Every application I have ever seen has been built for one purpose, to give the client some interface so that he/she can maintain his/her data. An application has never been built because clients wanted their business modeled in a "perfect" object framework. OO is great for producing much more sound applications, but those applications are built to maintain a separate datastore. This is how it is, and no OO argument will change that.

So, let me reiterate, to clients, Data is King! Because of this fact, and the fact that relational databases have proven themselves fantastic at protecting and maintaining clients data, then, the corrolary is, the database is king. The OO model of the application, or any model for that matter, is completely secondary to the database

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

What exactly is wierd or ineffective about this? You can tell an object to create itself and have to do nothing else, so what?

When a client comes to me and says, "I need to see a report of all the delinquent accounts in my region". The fact that I would have to ask every single different object in the database whether it is part of this group seems wierd and ineffective.

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

WHAT? This says to me that you care more for the perfection of the completed application and how it fits into an OO model instead of caring for why one builds applications in the first place. Taking care of the data is the NUMBER 1 priority. No ifs ands or buts.

Sure, a relational database doesn't mesh perfectly in what you would think would be a perfectly designed OO system. So what? What then is OO solving if the client's needs have to take a backseat to the OO needs. Sure, you could build the perfect OO system if you could just use an OODB. So what. You can't build this perfect system, cause you have to make your application talk to and maintain the database. The database is king, and the application, OO perfection or not, is secondary.

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

Seems that you just glossed over a REALLY BIG POINT. Database's are industrial strength and it doesn't seem like you are ready to put your database up against these worldclass systems. You really think that a client wants to hear a consultant say, "Well, if you use an OODB, then you will have the most perfect OO model out there" To that bit of consulting, he's going to say, "who cares, and you are fired cause you don't know what I consider important" and then he will go find an Oracle consultant.

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