Re: S.O.D.A. database Query API - call for comments
Date: Mon, 23 Jul 2001 20:40:41 +0200
Message-ID: <9jhr7e$d0s$00$1_at_news.t-online.com>
Galen Boyer wrote:
> 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?
It depends.
If you access data through navigation, object databases can be considerably faster than relational databases.
If you frequently use complex queries, object databases perform badly. This is not a technical issue but a deficiency in the maturity of object database query engines. Indices for object databases can be very similar to those used in relational databases. If query optimizers reach the same development level, performance should be equal.
Another point to consider:
Object databases currently are not very mature, if indices might exceed RAM
limits.
> >> 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.
Just to get an idea:
Query query = db.query();
query.constrain(new Account());
query.descendant("balance").constrain(0).smaller();
query.descendant("postalCode").constrain("34").like();
results = query.execute();
while(results.hasNext())
Account delinquentAccount = (Account)results.next(); // do something with the account
}
Probably your class model is more complex than the above. If you post it here, I could try to construct an example for it.
The S.O.D.A. API is not very elegant for simple constraints. It is designed to be efficient for reusing objects, that are present in your application anyhow.
> >> >> Data integrity. Normalization gets rid of redundancy.
> >> >
> >> > Why?
>
> I don't understand your question. Just seems that you aren't
> caring about data integrity.
Of course I do care.
The point has been brought up before in my discussion with Bob. My answer
was:
"A clean class design can be used as such and does not need to be
normalized."
This is why he started the "Clean Object Class Design - What is it?" thread.
Part of the answer that developed:
- Use inheritance for "always is a"
- Use interfaces for "can be a"
[20 years]
> It seems you believe that applications can actually survive for
> this long.
Applications definitely wont survive. Business logic code can survive, if it stays away from proprietary APIs and systems.
> 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.
This is the status quo, yes.
I am not sure what will happen.
Widespread use of OO languages is only just developing.
The cost of a clean OO system only pays off in the long run. Who cares, if a solution is needed fast and cheap? Refactoring costs are rarely part of an initial calculation.
> The big iron is working fine
> and it will stay that way as well.
...and nobody can exactly calculate cost and outcome of "making things better".
> > 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.
A lot of issues like concurrency can be taken care of very nicely if logic remains among objects. Let's continue this discussion in five years.
For the time being object databases are a great help, if you already have a complex class model that you want to persist with as little work as possible and if you want to achieve the best performance possible in doing so.
If you have a monster business application running O.K. on an SQL database, switching to an object database right now would be a very stupid idea.
> Can you define, "save your chair".
"save your chair"-decisions:
Noone was ever fired for choosing Oracle, I believe.
> Oh, I think I see. Right now, the OODBs are still in
> experimental stages, and not ready for primetime?
Quite a few object databases have been around for some time. I wouldn't call them experimental. Objectivity claims to have the largest database on the planet. Objectivity servers were also sent into space with the Iridium project. Many telecommunication companies use object databases.
The specific advantages of current object database technology still are specific to certain usecases. I am sure this will gradually change, as more features will leave the "experimental" labs.
> You and others are trying to get the
> community to consider the possibilities?
I thought the discussion here would also be very good to get some help for S.O.D.A. It turned out to be a false assumption. :-)
> 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.
Todays object database customers typically have a different approach. They are seriously unhappy with mapping to relational and they are desperately looking for substitutes.
If your usecases don't drive you in the direction, you will probably be more happy with relational databases for the time being.
> 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.
Some points (not all are possible today):
- Handle concurrency issues among objects - Reuse GUI objects for queries - Typesafe refactoring - Only one single representation of reality - Zero table maintenance
Handling business issues "better" is not the only point.
It is very desirable to write as little code as possible.
It's cheaper, faster, more maintainable, binds less resources and can be
refactored easier.
Is there a thumb rule for the profit of being able to write an application
with half the code?
Kind regards,
Carl
--- Carl Rosenberger db4o - database for objects - http://www.db4o.comReceived on Mon Jul 23 2001 - 20:40:41 CEST