Thanks, Serge.
When you say "split the table vertically ," I'm assuming what my mind
says is horizontally. Ie, change
CREATE TABLE MYTABLE (
User_ID ...
Time_started ...
Time_Ended ....
Time_Signed ....
TextField1 ...
Textfield2 ...
. . .
TextFieldn ...
change it into
CREATE TABLE MYTABLE1 (
User_ID ...
Time_started ...
Time_Ended ....
Time_Signed ....
TextField1 ...
Textfield2 ...
and
CREATE TABLE MYTABLE2 (
User_ID ....
TextField3 ....
. . . .
TextFieldn
Then create a view that joins the two tables and expose only that view
to the user. As it happens, this view (tables) will very rarely have
deletes and never have updates (deletes will be done in batches and
run overnight). It will have inserts often.
Is an "instead of" trigger still desirable, would it allow inserts
more efficiently if only MYTABLE1 were needed? Would it avoid a null
entry into MYTABLE2 if that were not used?
When you say, "DB2 [can] figure out that ... it can save the join,
given e.g. some RI." -- Like what or how much RI? Every field?
Which fields?
SS
Serge Rielau <sr*****@ca.eye-bee-em.com> wrote in message news:<7d*********************@news01.bloor.is.net. cable.rogers.com>...
Can you classify the columns into logical groups that are used together?
One way would be to split the table vertically and place a view on top.
An instead of trigger can handle update/delete/insert.
If you only access one side of the table at a time DB2 figure out that
one it can safe the join, given e.g. some RI.
Cheers
Serge