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

[Bexley Hall]

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