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

From: Galen Boyer <galenboyer_at_hotpop.com>
Date: 23 Jul 2001 10:21:01 -0500
Message-ID: <u7kwzv786.fsf_at_verizon.net>


On Mon, 23 Jul 2001, carl_at_db4o.com wrote:

> Projects that are started today do intend to emphasize OO more.

Yes, every project I have been on has been OO, but always to maintain a relational store.

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

I don't know if this is the case, but what are the retrieval times. I have rarely had to worry about inserts as bottlenecks in performance. They happen much less frequently than updates and the biggest performance killers are retrieval, ie reading from disk. How well does an OODB do in that arena?

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

Please give an example of how a client would get the answer to the above question.

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

I don't understand your question. Just seems that you aren't caring about data integrity.

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

It seems you believe that applications can actually survive for this long. Maybe this is so and the promise of OO will actually come true, but most people believe that the data is what survives and new applications get written every other week to access and maintain it.

> Of course I know that the legacy systems out there prevent this
> approach.

Well, this is a perfect example of turning my argument on my own field. I think there are a bunch of relational biggots who think that all of the legacy code should be converted to relational, but the customer could care less. The big iron is working fine and it will stay that way as well.

> There are applications where a clean OO model saves 90% or more
> of the necessary work.

Now this would be something to take heed of. If you can show me how, using OODBs, clients can get at their information, do month on month comparisons, sophisticated data mining ... (Everything that one gets with a data warehouse and datamart structure) then I would think that you might have a point. But, if the reports and analysis isn't handled, then the necessary work is just that, necessary.

> 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 understand, but this is just the OO idea/promise, and not really supporting why we need OO databases. I agree that we need OO apps. OO is the best way of building apps, definitely agreed.

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

Can you define, "save your chair".

> Progress and technical advantages against the competition can
> never be achieved with "save your chair" decisions.

Oh, I think I see. Right now, the OODBs are still in experimental stages, and not ready for primetime? You and others are trying to get the community to consider the possibilities? Well, I am ready for that, but I need to see how today's issues are solved in the OODB framework to consider going down that route.

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

Yes, I think OODB has a long way to go. I'm just trying to understand what business problem does it solve. The only one I can see is that it makes the application development cycles shorte. This would decrease cost to the customer, which is a good thing. But, I don't see how the application that is built is better at solving the business issues that are currently being solved by relational technology.

-- 
Galen Boyer
It seems to me, I remember every single thing I know.
Received on Mon Jul 23 2001 - 17:21:01 CEST

Original text of this message