Re: table inheritance - useful?

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.
without.
--
Matthew Weigel
hacker
unique & idempot . ent