|
Nik,
That is a confusing comment. I would probably take it to mean that
only when a foreign key value is updated or inserted would R.I.
checking be invoked. Updating or deleting a primary key would not
invoke any checking. If this is what IBM means, it's not too
impressive.
"Supporting" referential integrity is a little vague, too. Rdb
constraints SUPPORT R.I. in that they detect the violation condition.
They don't totally implement R.I. in that they don't take specified
actions (e.g., NULLIFIES, CASCADES). They take only the action
"RESTRICTS."
A DBMS couldn't totally implement R.I. without understanding primary
and foreign keys of the USER relations. (DB2 has understood these keys
for SYSTEM tables from 1.0). It sounds like DB2 will have to at
least understand these keys now.
I don't know, that's just my shot at it. I usually have trouble
understanding what IBM really means anyway.
Paul Krug
|
| Initially, IBM announced full referential integrity, including
primary/foreign key support as well as cascading delete and null
support. However, two or three months after initial announcement,
industry consultants began reporting that cascading deletes will
no be supported initially. I have not yet heard what the technical
problem was that is holding it up.
I don know that the target date for DB2 Version 2 was set 3 or 4
years ago based primarily upon the time it would take to do referential
integrity. The performance and other features were the 'other' things
that were also possible during the same time. Even if the initial
release does not support full RI, it is just around the corner.
In comparison, Rdb can detect RI violations, but cannot yet do the
cascading either.
Jamey
|