Ticket #1332930 (Feature Requests)

Eric Stadtherr estadtherr at gmail.com
Tue Aug 15 14:49:38 CEST 2006


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?

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
> ---------------------------------------------------------

More information about the Dev mailing list