From: Sebastian Hanigk <hanigk@...>
Date: 2007-03-29T22:45:05+09:00
Subject: Re: Object/Relational Mapping is the Vietnam of Computer Sci

Jochen Theodorou <blackdrag@uni.de> writes:

> So for example I have class A with an attribute id and a class B with
> an attribute email and a class C that has the parents A and B and has
> an attribute name. Now what do we do? Make a table for A, one for B
> and one for C, or one table for all of them? Even if you simplify this
> to single inheritance, you still have that problem.
>
> When I for example use one table per class and link these tables
> together to represent the inheritance, then I get a massive problem in
> my queries. Because If I query on C I might have to query on A and B
> as well.

The inheritance relation of an ER model can be represented in the
table model as views. Depending on the circumstances, it might be
favourable to model the subclasses as distinct tables and the
respective superclasses as views or the other way around.

Either way, queries over the subclasses will query the superclasses, but
that's not different from the OO point of view.

> So if your objects can be mapped nicely to an relational database,
> then most possibly you are using a not so object oriented part of your
> object system.

As Austin already has mentioned, object modeling can be seen as a
special form of ER modeling - which explains the plethora of
dysfunctional and outright ugly object hierarchies one encounters in
software engineering because those people do not understand the
fundamental mathematics.

> * OODBs don't allow me to access the data in a different way than my
> original object modell:
> Well, is there really a limitation that prevents a OODB from saying
> that certain attributes of an class are really the properties of
> another class? This way I don't need to always create a full object.
>
> * OODBs have roots and I have to use these roots to navigate to my
> real object:
> db4o for example allows you to query on a per class base, so each
> instance can be root. You need other objects only for joins. see
> S.O.D.A.

The point is still valid: OODBs are not suited to represent arbitrary
views to the data as long as there isn't a possibility of creating new
object classes based on the query.

> I also think that the relational algebra is more advanced than
> everything an OODB could provide. I think most OODB queries will for
> example have a problem with operations like getting the
> maximum/minimum of something, or subtracting one attribute from the
> other and such things. So especially in cases of reporting OODBs are
> not that good, not unless you do many of the operations outside the
> database system.

While relational databases do have a sound mathematical foundation
in relational algebra and set theory (which faciliates optimising
queries in an efficient way), I haven't seen anything like that for
OODBs.


Sebastian