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... ,)

____
HTH, Dominique
My two favorites:
If the only tool you have is a hammer, you will see every problem as a nail. --Abraham Maslow
Bien faire, et le faire savoir...

  • Comment on Re: OO concepts and relational databases

Replies are listed 'Best First'.
Re^2: OO concepts and relational databases
by dragonchild (Archbishop) on Aug 02, 2004 at 18:18 UTC
    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 ...

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]
      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:

      ____
      HTH, Dominique
      My two favorites:
      If the only tool you have is a hammer, you will see every problem as a nail. --Abraham Maslow
      Bien faire, et le faire savoir...

[reply]
Re^2: OO concepts and relational databases
by Solo (Deacon) on Aug 02, 2004 at 20:24 UTC
    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.

    --Solo
    --
    You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
[reply]
      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.

      ____
      HTH, Dominique
      My two favorites:
      If the only tool you have is a hammer, you will see every problem as a nail. --Abraham Maslow
      Bien faire, et le faire savoir...

[reply]
        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.

        --Solo
        --
        You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
[reply]

In Section Meditations