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

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.

My approach would be completely different: - The object model is king.
- Business rules between objects are queens, the most expensive to write because the designer and programmer needs multi-domain-knowledge. If you build a complex application, try to protect these business rules and program them in a way that you can reuse them for the next 20 years. - Invest as little work as possible for the database. An O-R mapper or an object database can solve most problems.

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