Martin,
I understand the intent of the CASCADE, I was just under the impression
that the "contact_type" table in your first example (or the
contact_field_type table in my version) were "static" tables that
defined the existence of certain field types (phone number, email,
birthday, first name, last name, etc.). The type column in the contact
table would then reference the PK of the "type" table (through the FK
constraint) to describe which type of field was contained in that row.
You then wouldn't want to delete your type entry if there were no
referencing contact entries.
Does this make sense?
-Eric
Martin Marques wrote:
On Mon, 14 Aug 2006, Eric Stadtherr wrote:
Thomas,
I wouldn't put the cascade delete on the type constraint, though (you
don't want to lose the ability to enter phone numbers just because
you deleted your last phone number... Wink ).
On CASCADE means that if you eliminate or update a PK, it will cascade
to the refereced keys. If you eliminate the last phone number, you're
just eliminating rows that reference th PK, so no CASCADE is done.
Those CASCADE are more like, if you eliminate the contact, all the
info of that contact will be eliminated.
--
21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------
