Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: OO concepts and relational databases

by exussum0 (Vicar)
on Aug 03, 2004 at 11:02 UTC ( #379578=note: print w/ replies, xml ) Need Help??


in reply to OO concepts and relational databases

How do I link those abstractions together with has-a relationships? (RDBMSes don't have is-a relationships.)
That's what boolean and number types are useful for.

Simple example, a boolean type for male on a person. male = false, means it's a woman. It IS an is-a type realtionship. I could create a male and female abstract type with hard-coded methods called gender(), but that's a little inefficient.

Further more, you can do the same with numbers. For instance, when you have an address type table, if you normalized the country out to another table and used ids, you have an isa type relationship that would be accomplished by creating hundreds of tag classes, package America, package Canada, package Barbados, package St Vincent. But that's just OOP hell. It's a little outlandish and a poorer representation than saying an address has-a country than an address is of this country's type.

The latter example isn't the BEST one. Lets give another. Take books. They are escentially all of the same ilk. Some are text, some are novel, some are reference. I doubt someone is going to create a reference, text and novel supertype when a field describing it is more direct.

Classes are not tables and attributes are not columns In other words, there is (almost) never a 1-1 relationship between them.
Never use never. Someone will have an example where for them, a class->table relationship works well for them. It may not be complex, but it doesn't prevent it from existing. :)

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


Comment on Re: OO concepts and relational databases
Re^2: OO concepts and relational databases
by dragonchild (Archbishop) on Aug 03, 2004 at 12:41 UTC
    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

      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.

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://379578]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (5)
As of 2014-08-23 08:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (173 votes), past polls