Skip site navigation (1) Skip section navigation (2)

Re: table inheritance - useful?

From: Matthew Weigel <unique(at)idempot(dot)net>
To: austinpug(at)postgresql(dot)org
Subject: Re: table inheritance - useful?
Date: 2009-10-15 23:07:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: austinpug
Decibel! wrote:

> With inheritance, when you want to insert a bank account you just insert
> into bank_account. The relevant fields magically show up in
> payment_instruments. You can select from either table and you're looking
> at the same record (except for obviously having more fields in the
> bank_account table).

OK, interesting.  If I'm understanding this correctly, then, it's got a 
major limitation in the case of wanting to map tables and classes: 
you're still stuck querying once to determine type, and then querying to 
get the whole object from the child table afterward.

If you are trying to grab a bunch of rows that may or may not be in the 
same class, you're pretty much screwed, here.  So you can make the 
tables clearly resemble the classes in the design, and grabbing an 
object whose type you already know is pretty easy, but as a general 
system supporting serialization/deserialization it doesn't really work 
too well?

I can understand the uses of doing it the way it is, and I can see why 
it's the right approach from a database design perspective, but... I had 
hoped that it was intended for something like my purposes.

> Hopefully this makes some sense. If people are interested I can talk
> about what we have setup at the next PUG meeting.

That would be great. :-)  In particular, I'd be interested in hearing 
more about the performance penalties (if any) to enforcing referential 
integrity via triggers, and operating on tables with inheritance vs. 
  Matthew Weigel
  unique & idempot . ent

In response to

austinpug by date

Next:From: decibelDate: 2009-10-29 21:54:01
Subject: Fwd: Database Architect
Previous:From: Decibel!Date: 2009-10-09 16:53:03
Subject: Re: table inheritance - useful?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group