Subject | Re: [IB-Architect] Table Inheritance |
---|---|
Author | Tim Uckun |
Post date | 2000-07-17T19:59:23Z |
At 02:42 PM 07/17/2000 -0400, you wrote:
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.
I am not trying to say there is no reason for inheritance only that
allowing domain definitions to have triggers could very simply solve the
problem for a majority of users.
:wq
Tim Uckun
Due Diligence Inc. http://www.diligence.com/ Americas Background
Investigation Expert.
If your company isn't doing background checks, maybe you haven't considered
the risks of a bad hire.
>I proposed an alternative solution in which a base table containing,From a practical point of view.
>among other stuff, the fields last_update_date and last_update_user
>and the triggers to maintain those fields. Other tables could then
>"extend" the base table, inheriting both the fields and the triggers.
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.
I am not trying to say there is no reason for inheritance only that
allowing domain definitions to have triggers could very simply solve the
problem for a majority of users.
:wq
Tim Uckun
Due Diligence Inc. http://www.diligence.com/ Americas Background
Investigation Expert.
If your company isn't doing background checks, maybe you haven't considered
the risks of a bad hire.