[Tfug] Inheritance in RDBMS's (PostgreSQL, Oracle, et al.)

[Dave Thompson]

Inheritence implementation is vendor specific, so if you decide to use it,
you may be locked in to a specific database software.

I would go for three tables: 'person', 'man', and 'woman'. 'man' and 'woman'
have foreign keys that point to 'parent'. This schema is simple, database
independent, and it even works for the 'hermaphrodite' corner case (you'd
put records into all three tables for a hermaphrodite).

-Dave

On Thu, Aug 6, 2009 at 12:19 PM, Bexley Hall <bexley401 at yahoo.com> wrote:

> Hi,
>
> What's the downside of using inheritance in designing
> data models for RDBMS's?
>
> Converseley, are there any (LESS OBVIOUS) advantages
> to this approach?
>
> Any general issues to avoid or exploit to take better
> advantage of this capability?
>
> I return to my favorite "common sense" example for
> illustration -- an address book.
>
> E.g., one can define a "woman" to be a "man" with the
> added attribute of a "maiden name".
>
> A more reliable implementation might be a man is a
> *person*; a woman is a *person* with a maiden name.
>
> A person is a *name* with a date of birth, etc.  A
> name is a {first, middle, last} tuple.  etc.
>
> So, the man definition can be extended to include
> "man specific" attributes (e.g., ability to belch
> the alphabet, favorite beer, etc.) while the woman
> definition can be extended to include "woman specific"
> attributes (e.g., maiden name).
>
> Does any of this add (considerably) to the overhead of
> storing the resulting tables and/or accessing them?
> E.g., I envision an implementation might just create
> several tables and link them with unique keys to form
> whatever "composite table" is of interest (e.g., a
> table with belch_alphabet and favorite_beer attributes
> linked to a "person" table would represent the man
> table).
>
> One consequence of this is it forces man-s to be different
> from woman-s.  So, for example, presenting the man data
> would require a different "form" AND QUERY than presenting the
> woman data (the different form is intuitively obvious; but
> the different query is less so).
>
> Of course, presenting the *common* attributes of man-s and
> woman-s could still be accomplished with a single form/query
> referencing the underlying common object (e.g., "person").
>
> Lastly, anyone have any horror stories of using these sorts
> of features?  And, was the horror a result of a bad RDBMS
> implementation *or* design errors in the data model (if so, which?)
>
> Sorry if this is a bit to esoteric...  :<
>
> Thanks!
> --don
>
>
>
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20090807/8a895dba/attachment-0002.html>