Flamewar object databases vs. relational databases (was: Unknown SQL)

Bob Badour wrote:
> What is the rhetoric? Your product limits its use to people who know Java.
> In order to use your product, one must learn Java. If one must learn a
> language to use a product, one will learn a simpler language faster. As
> you correctly point out, the more redundant "concepts" one has to learn,
> the greater the effort.
>
>
> >Should I post a website link, that uses our database as a backend?
>
> Who cares? We already know that Java programmers can build websites.

If you use the website, you are using our database.

> Nope. My argument is you need to understand C to write C programs. You
> need to understand Java to write Java programs. You need to know the
> DBMS data model to query the data. Teaching a user about a single concept,
> call it relation or table or whatever, is easier than teaching users the
 differences
> between Array, Set, Bag and Collection.

My point:
If you program with Java, you can use our database without knowing anything about relational systems.

> >Relational databases map classes to tables
>
> No, they don't. The statement is simply untrue. Relational databases map
> classes to domains. As I mentioned before, if you took any time to educate
> yourself, you would already know this.
>
>
> >no matter how many unnecessary
> >in-between layers you invent.
>
> Since the supporting premise is untrue, the rest is meaningless.

You do have objects on one side and tables somewhere on the other don't you? No matter what words you use for what you do in between, you are mapping classes to tables, aren't you?

Don't come up with the ridiculous design of storing objects in relational columns as a counter-example. It is not used in practice and it provides no sensible querying mechanism.

> >Lets take Java as a starting point.
>
> Let's not.

Which programming language do you prefer?

> You want to store some of what? The representations? If an object instance
> has multiple possible representations, which one do you want to store?

You store objects.
Multiple representations?
They are represented by multiple access methods to objects within the programming language. They do not need to be persisted.

> Well, as a programmer, I would certainly want to know what happens to my
> inheritance hierarchies. I certainly would not want them to change without
> my knowing!

???
What you store is what you get back.

> I certainly would not want my array to turn into a hashtable just because
> some other application prefers to deal with the same data that way!

I would not want to care about what happens with my objects for persistence. If I have the chance here to save work and gain performance, what is the drawback?

> >The more work the database engine does
> >for me here, the more productive I can be.
>
> Huh? Inheritance hierarchies, arrays and hash tables are physical
> limitations imposed by the programming language. The more physical
> limitations the DBMS imposes on the data, the less productive you can be!

So your starting point is a relational database as a fixed paradigm? Sadly this currently seems to be the case for many development teams. With this blind decision they choose to spend 20 to 50% of their implementation work on mapping objects to tables.

Doing this

- performance is lost
- maintenance work is an awful job
- unnecessary complexity results in spaghetti programs

Tuning the system to make up for performance problems - business logic is misplaced to triggers and stored procedures - natural correct object hierarchies are replaced by design trade-offs

Kind regards,
Carl

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