use an object-relational mapping layer to provide the kind of support you desire. It is more portable and
doesn't rely on proprietary solutions. A lot of this work is trying to reproduce object oriented approaches
in a non-object oriented way. This results in a lot of work that shouldn't have to be done. Many
people face the problems you are describing and have come up with good solutions Simply use those
solutions rather than trying to figure it out for a given database engine.
My $0.02,
Dave At 04:07 PM 12/29/2003, Karsten Hilbert wrote:
> > Nope. As much as I love PostgreSQL it doesn't support > > *really useful* table inheritance. > It is *very* useful, believe me. Despite a few minor grudges. LOL. No need to convince me as I am the one who had the guts to depend on table inheritance in the GnuMed schema :-)
However, "minor grudges" is an understatement as one needs to be *very* careful about things:
don't (try to) inherit triggers don't (try to) inherit foreign key constraints be extra careful about "inherited" primary keys - it is ALWAYS a good idea to let them be of type SERIAL
> > - primary keyness doesn't inherit
>
> No. But you can manually set the primary key constraint in the child table to
> the parent's primary key. This is actually necessary, since not in all
> derived tables you actually want the parent's primary key to be the primary
> key.
Ah, well, I should have been more precise. Key value
UNIQUENESS doesn't inherit. But in many cases one does want it
to be unique. That's the catch.
>> - foreign key constraints are broken ... > Yes, this is a bit extra work. But even without it, table inheritance is > already really useful (see our very own audit trailing system in gnumed) Well, ROTFL, like, I wrote it. But note how we attach the actual audit triggers to the leaf tables !!
Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
