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

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 4 | next ›
Discussion Overview
groupaustinpug @
postedOct 8, '09 at 6:00a
activeOct 15, '09 at 11:08p

3 users in discussion

Matthew Weigel: 2 posts Jon: 1 post Decibel!: 1 post



site design / logo © 2021 Grokbase