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

Bob Badour wrote:
> >Pointers and OIDs are preferrably *not* visible.
>
> Actually, you cannot hide them completely. I thought that Lee already
> covered this one with you. Just because the use cannot display a textual
> representation of the OID does not make it invisible. The navigational
> requirement implies that the OID is visible no matter how much you try to
> disguise that fact.

If there is no method to access the OID it is *not visible*.

Using navigation the user does not use or see any OIDs.

> > > How do I ensure that all of my users exercise the correct code?
> > > If they
> > > run last year's version, my company might not be in full compliance
 with
> > > federal
> > > statutes.
> >
> >By not allowing old versions to log in.
>
> In other words, I have to change all of my applications to use the latest
> versions or the applications no longer work. In a relational system, I can
> still run my older applications and I cannot avoid the current
> constraints -- all without changing a single line of my application code
 or
> even recompiling.

In Java you use Jars and namespaces to allow exchanging libraries and the behaviour of programs by just copying one single file into the CLASSPATH.

No, in a relational system, you cannot run older applications that are dependant on the existance of table x with column y. Changing these in the application is awful search-and-replace of strings without the help of the compiler. Because relational systems are so awful to maintain, older applications typically use old columns for new usecases. Instead of having meaningful table- and columnames, you often find separate documentation like "column drivers_license now contains the social security number". You might also have views to do this.

> >How many object databases did you test so far?
>
> Enough. I used to maintain the code for a proprietary network model
> database as part of one of my early jobs.

Early jobs?
So your experience gos back to 1987?
You might like to try some newer products. Development does continue.

[Person, Employee Manager example]
> >Why don't you supply the design that you would use?
>
> No such single design exists. There are innumerable designs I might choose
> depending on the full set of requirements.

Gee!
Designing relational databases must be really difficult, if there is no rule, how to put this really simple design together. With Java classes it is all straightforward. There is nothing to talk or think about:

class Person
class Employee extends Person
class Manager extends Employee

I would be very interested to hear about your "innumerable" designs. You must really have a hard time to decide on a direction to get going in practice.

> >I was trying to point out that the choice of data model has an impact on
> >performance.
>
> Well, it doesn't so you might as well give up now.

Of course it does make a difference, if I place the above in 1, 2, 3 or more tables.

> >Outer joins are essential.
>
> No, they are not. Your statement is simply untrue.

Where do you live and how simple are the programs you create?

Kind regards,
Carl

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