At 11:20 PM 7/21/00 +0100, Phil Shrimpton wrote:

>
>You have a base table that contains three fields ID, TIMESTAMP, USERNAME.
>You also have a trigger on this table that enters values into the TIMESTAMP
>and USERNAME fields if ID is an even number.
>
>You then create descendant tables to you hearts content.
>
>Q1) Do the descendent tables use the same trigger, or do they get a new one
>inherited from the one on the base table?
>

Ah! Smoke and mirrors! There is really only one actual table --
the base table. The descendent tables are virtual -- views -- of
the base table. Other than a little hackery to keep descendents
of a different branch from firing (and probably a few other
annoyances), the existing mechanisms all work. So the answer is:
there is only one trigger on exactly one physical base table.

>Several weeks later, you decide to change the TIMESTAMP field in the base
>table, to two fields DATE and TIME, and you also change the trigger to enter
>values if ID is an ODD number.
>
>Q2) Are the TIMESTAMP fields in the descendant tables replaced by the two
>new ones as well

There was only one physical TIMESTAMP field. It gets replaced, by
the current mechanisms, with two fields. Then the system tables
have violence applied to them. When the dust settles, a slightly
different set of mirrors (smoke is recycled and reused).

>Q3) Are the Triggers in the descendant tables updated to reflect the
>changes, if so are they 'auto re-compiled'
>

No BLR recompilation is required. The internal, in memory, representation
may be trashed and rebuild, but that is the extent of the damage.

>Again, I might be going off at a complete tangent here, but I can see good
>use for one method, and a complete nightmare for the other..
>

Jim Starkey