Re: Flamewar object databases vs. relational databases

From: Carl Rosenberger <carl_at_db4o.com>
Date: Sat, 21 Jul 2001 23:29:14 GMT
Message-ID: <9fboif$n2q$04$1_at_news.t-online.com>

Todd Gillespie wrote:
> : Again:
> : How would you insert
> : - two rows into a relational database

Hi Todd,

you have already posted your solution in your other Perl example:

You use the "_seq.nextval from dual" approach, that ORACLE recommends in the documentation. I was trying to point out that insertion of joined multiple rows requires data to go back and forth between client and server. In your example this does happen. This is where quite a bit of performance is lost.

> : - where performance is of less importance than integrity
> ??? not sure how this is relevant as we are not designing the DB..

You could generate primary keys in a different way by prefetching a set of 100 or whatever from the server.

> : - and multiple-users access the database
> ??? this is handled by the database...Oracle has MVCC locks, btw.

You could use select(max) or select _seq.curval in your insertion statement otherwise.

> : Man or wimp?
> : Programmer or bubble-blower?
> : Can you solve this problem or not?
>
> Where's the fire?

I was waiting for Bob to provide an answer. No matter with what he comes up with, there are drawbacks and performance deficits against an object database that inserts an inheritance hierarchy with one single statement. He has been trying to neglect this with "bullshit" and "not true" answers and by being reluctant to post a single line of code. It is very easy to watch a circus from the outside yelling "terrible" and "stupid" if you don't have to perform yourself.

> Oracle is a difficult beast. I have seen many people perform many
> boneheaded installations that cripple performance. The installer
> defaults, in particular, are not to be trusted.
> So if you are not well versed in Oracle DBA techniques, we cannot take
> your stats as gospel. You will no doubt complain about Oracle's
> indifference to beginners, but I have no shelter for that affliction. And
> I fear, from your past postings, that you are not an Oracle Achiever.

No doubt, I am not.
If you do have any database engine running next to you, ORACLE ot whatever: Running our benchmark code will cost you a maximum of 10 minutes. - Download our engine.
http://www.db4o.com/db4o/db4o.zip
- Extract to a directory of your choice. - Enter your JDBC connection settings to connect to your database in com.db4o.bench.BenchMark.java

- compile this file with javac
- run com.db4o.bench.BenchMark with db4o.jar in the CLASSPATH
- The benchmark code creates tables automatically and writes the results to

System.out.
Please post your results here, if you wish. Note that you might not be permitted to post benchmark results by a possible licensing agreement that you have signed with your database vendor.

> H: "Of course I won the fucking sword fight," Hiro says, " I'm the
> greatest sword fighter in the world." (in the electronic Metaverse)
> R: "And you wrote the software."
> H: "Yeah. That, too," Hiro says.

Of course this is always an argument to mistrust other peoples benchmarks. Feel free to rewrite the code to use prepared statements and another pkey generation if you wish.

Our simple type benchmarks are not in our favour at all, since we store an object *plus* a simple type, whereas a simple type *only* is stored to relational databases.

> Many, many people seem to be successfully using all 4 levels of JDBC
> interfaces, and writing their own wierd interfaces more often than is
> proper. It is also unwise to assume Java in some way 'special' and
> inaccessible to relational DBs. It's an almost-Turing machine just like
> any other language, and thus its constructs can be rewritten in any other
> language. Marketing does not change that.

Of course writing your own JNI driver will produce a better result. Would that be an intelligent recommendation as a consultant? "It depends" :-)

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com

Received on Sun Jul 22 2001 - 01:29:14 CEST