Database Design Theory?

Gabriel Gunderson gabe at
Tue Nov 8 22:27:32 MST 2005

On Tue, 2005-11-08 at 19:30 -0800, Jonathan Ellis wrote:
> I tried to use PG inheritance in a project earlier this year.  It
> quickly became clear that it's not very useful except for toys.  Which
> is unfortunate, because it has the potential to make life a lot easier
> in some situations.

It's certainly not the main selling point of PostgreSQL, but it's very
handy in the right situation (not all of them being toys).  The fruit
example was contrived to fit the request.  There are other very useful
ways to use it.

One way works more like an "interface" then "inheritance."  Let's say
that you had an app that validated shipping addresses.  You could make a
table that defined what a shipping address is and then inherit from that
table for your "accounts", "stores" and "taco shops" table.  You now
know that all of the new tables have the exact same underlying fields
that you build your validating code against.  And you can run the same
code against each of the tables because they implement that interface.
Because it allows for multiple inheritance of tables it can work like an
"is a" or a "has a."  Thats kinda cool if you ask me.  And you didn't
give anything up to try it.

Another thing thats nice is you can SELECT from the base table and get
all of the shipping address in one shot (no need to do what would
otherwise be a messy bit of SQL).

All of the complaints that you will hear about inheritance are
concerning PKs.  PG leaves PK with inheritance up to you.  I don't see
that as a weakness if it gives me flexibility.  And none of the
developers are tackling it because it's not a hot topic.  I kinda look
at it like updateable views.  Just because the developers can't settle
on a "best approach" it doesn't get advanced.

Anyway, long winded opinion that will sway nobody.

You should play around with them some more and see if you can't figure
how to best make them work for you.  Or, not.


More information about the PLUG mailing list