http://www.perlmonks.org?node_id=379607


in reply to Re: OO concepts and relational databases
in thread OO concepts and relational databases

You're saying that columns can have an is-a relationship with abstract types. That's equivalent, in my mind, to saying that the attributes of an instance have an is-a relationship with the native datatypes of the language I'm working in.

IS-A and HAS-A are more often discussed in reference to the object, not the attributes. That would, in my mind, correspond to the row in the table or the table definition itself. So, tables don't have IS-A relationships. Rows in tables don't have IS-A relationships. A given row in a table has a HAS-A relationship with every row that it is the N side of a 1:N relationship. (The confusion might be arising in that OO theory gives the container the HAS-A control while DB theory gives the contained the HAS-A control.)

That said, you can approximate an IS-A relationship between tables, but it's cumbersome and prone to mistakes. (It's kinda like doing OO in AppleBASIC or Fortran.)

------
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

Replies are listed 'Best First'.
Re^3: OO concepts and relational databases
by exussum0 (Vicar) on Aug 03, 2004 at 16:28 UTC
    Data is data in the long run. And you are right, "That said, you can approximate an IS-A relationship between table..." It's just a perspective that can hold true. Not that anyone should design with it in mind.

    Long run: given a row, is-a relationships can be derived by single tables sometimes. :)

    Bart: God, Schmod. I want my monkey-man.

Re^3: OO concepts and relational databases
by Solo (Deacon) on Aug 03, 2004 at 19:51 UTC
    That said, you can approximate an IS-A relationship between tables, but it's cumbersome and prone to mistakes.

    This statement seems contradictory to your idea about a separate table for optional attributes. That is merely a further generalization of the approximate IS-A relationship, and is equally cumbersome and prone to mistakes, if not moreso.

    How is it more cumbersome to have the tables

    Animal .id .name .type Mammal .animal_id .hair_color Reptile .animal_id .num_of_limbs

    Than to have the tables you are proposing?

    Animal .id .name .type AnimalAttribute .animal_id .attribute_id .value Attribute .id .name

    --Solo
    --
    You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
      Those solve different problems. The first solves the IS-A problem and is the cumbersome and error-prone solution I was referring to. The second solves the problem of a large number of optional attributes and is an alternative to having dozens of columns in your main table, most of which are NULL for any given row.

      There have been situations where I will use both solutions for different issues in my design. In fact, you can use both solutions for the same tables, if you need it.

      And, the two solutions can be considered interchangeable, for a limited subset of IS-A problems. But, the second solution becomes very unwieldy for most IS-A problems.

      ------
      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