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

Bob Badour wrote:
>>> Go back and read my original email on this topic for an abbreviated
>>> list of the ways that different OODBMSs differ in subtle and
>>> confounding ways.
> >
> >After reading all your postings in this thread I can not find a list of
 the
> >differences.
>
> That's odd. You must have missed this one:

[...]
[irrelevant posting snipped]
[...]

[what remains]
> Network model databases, however, represent data with pointers and other
> physical constructs that vary greatly among different vendors. Further
> issues such as shallow copies vs. deep copies, pointer swizzling, implicit
> back-pointers etc. vary as well. Every different implementation of network
> model database changes the meaning of the data implied by physical
> constructs by introducing often subtle differences in interpretation.

This is it?
Your list of points is quite irrelevant in practice. Object databases differ by tons of further details which are by fay more important than the ones you listed.
Doug Barry maintains a factbook on object databases, to bring some light into drastically differing products.
http://www.odbmsfacts.com/

Object databases do have one issue in common: They try to hide implementation issues from the user. Pointers and OIDs are preferrably *not* visible.

[changes of implementations over years]
> >The work to reflect changes is to be done in the programming code, am I
> >right?
>
> Nope. Many applications need not change at all because their specific
 needs
> might not change from one year to the next. Logical independence,
 delivered
> by views, provides all that's necessary. Of course, that subset of all the
> applications that do need to change from one year to the next will have to
> change in the code. Presumably, they might use new views on the database
 as
> well.

I don't understand where you are headed here. In a previous posting you implied that some handling might be changed. Certainly business logic can not be changed by rewriting views.

> >There are object databases that automatically handle schema changes.
 Still
> >there is no maintenance work necessary to adjust the database schema. It
> >will continously be analysed by the database engine.
>
> Right. And if pigs had wings they would fly. I suppose I just imagine the
> schema change I want, the database reads my mind and takes care of all the
> rest?

No.
You change you classes *only*.
There is no need for a change to tables, mappers, queries, backups and whatever.

> >If you think you need proxy objects to provide a different view at
 employee
> >objects from HR and from Payroll, why not create the classes for them?
>
> What exactly is a different view at an employee object? Is it a different
> view at the data? Is it different behaviour? Why would I want to create
> different classes for them at all? It's much simpler to create relational
> views in the database and handle application issues in the applications.

Whats your definition of "simpler"?
You can create object views in the same way as you can create database views. It is one intermediate layer that translates data.

> >If you want versioning, fine.
>
> Versioning is an inferior attempt at addressing physical/logical
> independence. When I want versioning, I use PVCS or SourceSafe --
> where it's appropriate. In the database, I will use relational views.

Are we talking about versioning of sourcecode or versioning of persisted objects?

As above:
Similar to relational views an object database can use classes/objects to translate data.

> >Why not work with different versioned classes derived from a base
 employee
> >class for the next year?
>
> 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.

> >IT does change, and it changes quickly.
>
> Ahhh, but sound fundamental principles change very slowly. It is precisely
> my knowledge of sound fundamental principles that has allowed me to
> adapt to the rapid changes in my industry.

You are about to miss a new tornado.

> >Object-oriented languages were not common 10 years ago.
> >Today they are.
>
> Well, I have been writing object based and object oriented programmes
 since
> 1987. Let's see.... that's 14 years. I guess that makes me an early
adopter.

How many object databases did you test so far? You might have been an early adopter 24 years ago. Early adopters also grow old and tired of changes.

> >It is time for object databases.
>
> Bullshit.

I wish you would always use this argument. It would save me a lot of work answering.

> >Compare the following:

<repost because deleted>

1.)
table Person
  int personPkey
  String name
  boolean isEmployee
  String employeeID
  boolean isManager
  String managedDepartment

2.)
table Person
  int personPkey
  String name

table Employee
  int employeePkey
  int personFkey
  String employeeID

table Manager
  int managerPkey
  int employeeFkey
  String managedDepartment

What is your favourite flavour?

1.)
SELECT * from Person
  WHERE isManager = true

2.)
SELECT * from Person, Employee, Manager
  WHERE personPkey = personFkey
  AND employeeFkey = employeePkey

Version 1. will result in a monster table, totally unhandy and very unperformant.

Version 2. will get you ugly unperfomant queries, ugly subselects and ugly outer joins. Would you like to provide a solution for "<all employees>, <and their possible managed department, if they are managers> WHERE <the name is 'Badour'> <but I don't want managers of the department 'flames'> ?

</repost because deleted>

> It's not hard for someone as ignorant of database principles as yourself
 to
> build a straw man by comparing two horrible designs.

Why don't you supply the design that you would use?

> >What is your favourite flavour?
>
> They both suck. What's your point?

I was trying to point out that the choice of data model has an impact on performance.

> Of course, the peformance is totally independent of the data model. You
 can
> verify this for yourself by creating the design in a variety of database
> brands and comparing the different performance even though the designs are
> identical at a logical level.

???

> I disagree with all of your conclusions regarding what I will get. I don't
> consider outer joins relational; I think that NULLs are Codd's big
mistake.

Possibly.
Today we have to live with NULLs.
Outer joins are essential.

> The object-relational mismatch exists because relational languages are so
> much higher-level than current object languages.

???

> Wrong. OIDs are exposed to users whether they see the actual
 representation
> or not.

???

> When the OODBMS forces one to access a contained collection through
> the containing object class, it exposes the linkage to the user.

The linkage is accessed in the programming language with the notation object.member

This is natural in OO languages and typically does not cause programmers headaches.

OIDs are not exposed.

[Object database handling of OID]
> So every vendor transparently handles every other vendor's OID
> transparently? Get real!

In fact this happens, if OIDs never appear in application code, which they don't have to.

You might like to experiment with some object databases to understand how this works.

Kind regards,
Carl

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