From: | Thomas F(dot)O'Connell <tfo(at)sitening(dot)com> |
---|---|
To: | jao(at)geophile(dot)com |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Any reason not to use inheritance? |
Date: | 2004-09-21 02:55:20 |
Message-ID: | AD0FCDDD-0B79-11D9-99C2-000D93AE0944@sitening.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
If the scope of your inheritance (as in, number of children you expect
per parent) is reasonably limited, this can be convenient. But if the
number of children grows large, and you discover that you need indexing
or constraints, you will need to develop triggers that can manage
everything and generally spend a bit more time on manual intervention
than if you relied on a normalized data model.
-tfo
On Sep 20, 2004, at 5:16 PM, jao(at)geophile(dot)com wrote:
>> I've yet to encounter a scenario that actually required inheritance.
>> I've used it a few times, but when I have, the end result always
>> required a bit more work because of the incomplete aspects of the
>> postgres implementation (namely constraints and indexes).
>
> Could you expand on this?
>
> All indexes and constraints would be declared on the child tables.
> Nearly all table reference would be to the child tables. (So why use
> inheritance at all? If for no other reason, all the common
> columns would be declared in one place.)
>
> Jack Orenstein
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2004-09-21 02:57:20 | Re: using database for queuing operations? |
Previous Message | Kevin Barnard | 2004-09-21 01:23:22 | Re: using database for queuing operations? |