Re: OO concepts and relational databases

[dfaure]

in reply to OO concepts and relational databases

Getting back to the OO concepts (and btw answering the quiz I proposed here), you have 3 available ways of modeling your data relations:

Aggregation: aka "is part of"

The datas are modeled as highlevel objects containing sub objects of lower level on the divide to conquer priciple.

Association: aka "is linked to"

This relation maintains the relationships between the different parts of the objects model constituted with the datas.

Heritage: aka "is a"

The most famous concept of OO culture (perhaps because of its specificity), and certainly the badly used. A very common mistake of OO beginners consists in believing that everything should herit from something else without asking themself before all if this object is really a kind of that object or not.

The only real common data relation shared between OO and relationnal data model is the association. The two other one may be more or less emulated with frustrating results and poor performance as other monks have already pointed out in this thread.

So, why not try to use a OODBMS instead of a RDBMS? In other terms, something more dedicated to the way datas is described as objects. Despite they are still less known and used than RDBMS^*, some engines are up and ready, waiting you to try them, even with perl (look for Pogo)!

____
* Sorry to say that, but my signature first favorite citation totally applies here... ,)

[dragonchild]

There are two reasons why I didn't address OODBMSes:
1. MySQL, Oracle, SQLite, and PostgreSQL are all RDBMSes. As those are the most popular options mentioned here, I chose to discuss them. I actually haven't seen much, if any, discussion of OODBMSes on this (or any other) site I go to.
2. I've never used one, so I don't have any experience to discuss them. I have, however, a lot of experience with Oracle and MySQL in a number of companies. :-)

You may be perfectly correct in your assertion of OODBMSes. I don't know. I'd certainly be interested in learning more, though ...

[dfaure]

There are two reasons why I didn't address OODBMSes

And you're perfectly right. For now OODBMSes are still more than ever small exotic things compared to mastodontic RDBMSes (commercial rules applies...).

In fact, I always found RDBMSes complex and difficult stuff, even a bit archaic (the gap from sequential-indexed files is not so wide).

Here's some interesting reference about OODBMSes:

• Object Oriented Databases
• Object-Relational Database Management System

[Solo]

The only real common data relation shared between OO and relationnal data model is the association. The two other one may be more or less emulated with frustrating results and poor performance as other monks have already pointed out in this thread.

Relational models often include 'IS A' relationships for many of the same reasons OO designs do. Supposing you have a table Vehicle, you might need tables Truck and Motorcycle to hold information specific to only some of the rows in Vehicle. This is commonly modeled as a 1 to 0 or 1 relationship between the generic table and the specific table, but other implementations are possible. My results have never been frustrating, and performance is not generally a factor in this design choice.

[dfaure]

Supposing you have a table Vehicle, you might need tables Truck and Motorcycle to hold information specific to only some of the rows in Vehicle.

You're describing here a design rule able to emulate an heritage, which is mostly a matter of methodology/dba experience.

With a (real) OODBMS, this kind of trickery relational modelisation is not required.

[Solo]

You're describing here a design rule able to emulate an heritage, which is mostly a matter of methodology/dba experience.

With a (real) OODBMS, this kind of *trickery* relational modelisation is not required.

Well and good to use an OODBMS if one is within your options. I make no assertions about whether an RDBMS or OODBMS is more appropriate.

However I will not allow it to be said RDBMS do not support ISA relationships, when they are clearly supported and the relationship follows directly from normalization. It is not trickery, nor even unusual.

Update: Removed inflammatory language that was not meant to be so.