Re: JDO comparisons

"Carl Rosenberger" <carl_at_db4o.com> wrote in message news:<a4mlrp$2ne$00$1_at_news.t-online.com>...
> Eric Samson wrote:
> > JDO QL can surely be improved, you're right.
>
> My 2 cents:
> JDO QL is not worth improving.
> It can simply be thrown away.
>
>
> > But the initial question was about going on with JDBC or switching to JDO.
> > How do you simply QUERY MAPS with JDBC ?
> > How do you deal with simple collections or inheritance ?
>
> The problem is:
>
> The installed base of applications relies heavily on complex
> SQL queries. JDO QL is by no means a replacement.
>
> There are some rare complex object-oriented applications
> that need deep inheritance hierarchies. These applications
> have been flirting with object databases in the past.
> New projects might consider to go for JDO since there is
> small hope, that quite a few vendors will support the
> standard. The drawback against JDO implementations that
> map to relational databases:
> They are slow and they will always be slow.
>
> I see three prototypes of customers:
> (1.) Business applications with normal flat hierarchies:
> They will continue to use SQL since they need the
> query capabilities.
> (2.) Applications with deep inheritance hierarchies and
> high demands for performance:
> They will get the best results with the tightest
> object database integration they can get. Additional
> overhead by routing through a JDO layer [1] will not
> be benefitial.
> (3.) Developers looking for the easiest way to store
> objects. They will not like JDO since it is much
> more complex than necessary.
>
> Where are the JDO customers?
> Of course there will always be mainstream idiots
> that value company names higher than technology.
> Too bad for them. Go with Enron.
>
> We target the customer types (2) and (3) and we feel
> that we will get along perfectly without supplying
> a JDO implementation. Should JDO be around in a year
> or two and should the JDO query interface be replaced
> by something decent, we still have the decision open
> to invest the manyear to provide a JDO implementation
> on top of our API.
>
>
> Kind regards,
> Carl
> ---
> Carl Rosenberger
> db4o - database for objects - http://www.db4o.com
>
>
> [1] I expect all quickly available JDO implemenations
> to be add-ons to existing database engines. The JDO
> part will be an intermediate library like you seem
> to be providing one.

Carl

1. JDO for SQL too slow. This mainly depends on the implementation. On standard objects manipulation we show better performance than JDBC, for instance just because we have a client cache (as an ODBMS). About queries, we know this objection, and address it giving our LiDO-JDBC users a way to map SQL queries and compiled queries when they need manual tuning.
2. Our JDO Versant implementation is even faster than the Versant Java interface. The JDO client wrapping layer around an ODBMS is not something important, regarding other global performance factors like network usage and so on. (BTW one prospect requested us for db4o support ;-)
3. a JDO application is as easy to code as if you had an ODBMS (it's a virtual OBDM on top of any physical data store). I know the very long "discussion" you had with JDO experts a while ago, IMHO it mostly comes from your reluctance of what JDOQL is (probably yet another endless holly war in the "Object Query" arena).

I can see the JDO community growing very fast these days. I wish you all the best with db4o which is a nice, well-targeted product.
I'm quite sure you'll join the JDO wave sooner or later.

Best Regards, Received on Mon Feb 18 2002 - 05:39:00 CST