Subject | Re: [IB-Architect] Table Inheritance |
---|---|
Author | Jim Starkey |
Post date | 2000-07-17T20:08:37Z |
At 01:59 PM 7/17/00 -0600, Tim Uckun wrote:
of the table inheritance models for a variety of reasons:
1. The RDB$TRIGGERS table would need at least a RDB$FIELD_NAME
column to tie the trigger to a domain (leaving RDB$RELATION_NAME
null). This would break an unknown number of DDL handling
programs in unknownable ways.
2. There is no obviously way to merge trigger fire order from the
domain space into the table space.
3. Mechanism that require multiple fields are hosed. My example
would work, but if it were extended with previous_update_date
and previous_update_user, it couldn't.
Encapsulating the column and trigger definitions into a single
mechanism has a nice piece of elegance, you much admit.
Jim Starkey
>That actually is substantially more difficult to implement than either
>The need for maintaining multiple triggers in the first place could be
>alleviated by allowing triggers in domains. More often then not the reason
>you are writing the same trigger over and over again is not because the
>tables are almost the same it's because they contain the same field.
>
of the table inheritance models for a variety of reasons:
1. The RDB$TRIGGERS table would need at least a RDB$FIELD_NAME
column to tie the trigger to a domain (leaving RDB$RELATION_NAME
null). This would break an unknown number of DDL handling
programs in unknownable ways.
2. There is no obviously way to merge trigger fire order from the
domain space into the table space.
3. Mechanism that require multiple fields are hosed. My example
would work, but if it were extended with previous_update_date
and previous_update_user, it couldn't.
Encapsulating the column and trigger definitions into a single
mechanism has a nice piece of elegance, you much admit.
Jim Starkey