Unique columns in the parent tables can't be guaranteed except with
triggers. Since I like my data models to be unable to go incoherent
(who doesn't) you end up putting triggers on those tables which is
paying performance & implementation complexity for something that just
works with normal tables.
I was also lured into using inheritance since it looked so logical. But
I went back to a master table + separate tables instead of children.
Unless you have a compelling reason I'd stay away.
David Helgason,
Over the Edge (http://otee.dk), making great game technology
On 21. sep 2004, at 00:16, jao@geophile.com wrote:
> Quoting "Thomas F.O'Connell" <tfo@sitening.com>:
>
>> Just beware that inheritance is not a complete methodology in
>> postgres.
>> The implementation has limitations. For instance, indexes in parent
>> tables will not be inherited by children.
>>
>> 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.
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match
>
