Re: S.O.D.A. database Query API - call for comments
Date: Mon, 23 Jul 2001 12:09:53 +0200
Message-ID: <9jgt9o$6li$01$1_at_news.t-online.com>
Galen Boyer wrote:
> > 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.
Very probably object databases will need this functionality to gain more noticeable market share. Some vendors have already moved in this direction.
> 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
This might be true for large existing business databases.
Projects that are started today do intend to emphasize OO more.
> > 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?
Inserts perform better since no queries need to take place. It's not a "so
what" advantage:
Inserting complex object structures can be powers of 10 times as fast.
> 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.
This is a different point and has little to do with IDs.
S.O.D.A. has a declarative query interface, designed exactly for problems
like this one.
http://www.odbms.org/soda/
> >> > Where is the advantage of relational databases?
> >>
> >> Data integrity. Normalization gets rid of redundancy.
> >
> > Why?
>
> WHAT?
I might sound picky here:
You haven't answered my question.
> The database is king, and the
> application, OO perfection or not, is secondary.
Of course I know that the legacy systems out there prevent this approach.
> 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.
There are applications where a clean OO model saves 90% or more of the necessary work. The benefits of OO are not too large for first-time-implementations. OO really gets strong when it comes to refactoring and continous development.
I agree with you for simple business applications. Choosing ORACLE is the "save your chair" mentality. A client doesn't need a consultant to choose ORACLE. Progress and technical advantages against the competition can never be achieved with "save your chair" decisions.
New products have to overcome two hurdles:
First they need at least the stability of old products that are said to have
"industrial strength".
Second they need to develop this credibility among potential customers.
It's a long way to go.
Kind regards,
Carl
--- Carl Rosenberger db4o - database for objects - http://www.db4o.comReceived on Mon Jul 23 2001 - 12:09:53 CEST