----- Original Message ----- 
From: "Steve Lefevre" <[EMAIL PROTECTED]>
To: <mysql@lists.mysql.com>
Sent: Monday, April 11, 2005 12:26 AM
Subject: foreign key design stratgies


> Hey folks -
>
> I'm having a little problem understanding ON DELETE foreign key
> constraints. Here's my options from the manual:
>
> [ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT}]
>
> When do I use each one? I can find anything in the online manual that
> suggests how to construct a database using this.
>
I'm not surprised; the manual is pretty weak on design issues for the most
part.

I am rushed for time so I am going to be fairly brief and superficial in my
answer but it should be a reasonable start for you. By the way, I am gong to
talk about foreign keys more from the perspective of DB2 than MySQL because
I've used DB2 a lot longer; however, I'm reasonably sure that they work
exactly the same way in MySQL as DB2 (or Oracle, or Microsoft SQL Server, or
...) since they all tend to write towards the same SQL standards.

The delete rule for a foreign key always describes what should happen to the
child/dependent rows if the parent row is deleted. Picture a table named
DEPT containing one row for each department in a company with the primary
key being DEPTNO (department number). Picture another table named EMP
containing one row for each employee in the company with the primary key
being EMPNO (employee number). Each row in the EMP table also contains a
department number (WORKDEPT) that represents the department in which the
employee works. WORKDEPT is then a foreign key pointing to the DEPTNO column
of the DEPT table.

If your delete rule is RESTRICT, you are saying that you cannot delete
department D21 from the DEPT table if anyone in the EMP table has a WORKDEPT
of D21. If you try, the database will give you an error message about an
invalid delete of a foreign key and the delete will fail. Therefore, if you
want to delete department D21, you first have to get rid of all rows with a
WORKDEPT of D21 in the EMP table. You could do that by deleting those
employees first or by assigning them to different departments via UPDATE
statements.

If your delete rule is CASCADE, you are saying that you can delete
department D21 from the DEPT table regardless of how many people in the EMP
table have a WORKDEPT of D21; the delete of the DEPT row for D21 will also
cause all rows of employees with a WORKDEPT of D21 to be deleted as well.
Furthermore, if those employee rows are linked to rows in other tables via
foreign keys, those rows will be deleted as well. This is not limited in
depth so it could cause a *lot* of deletes. Therefore, if the D21 employees
were also present in tables that listed employee health claims and the
company baseball team, they would also be deleted from those tables and any
dependents of THOSE tables as well, ad infinitum.

If your delete rule is SET NULL, you are saying that you can delete
department D21 from the DEPT table regardless of how many people in the EMP
table have a WORKDEPT of D21; in this case, the employees in the EMP table
who have a WORKDEPT of D21 will have their WORKDEPT value changed to null
but the rows will still be in the table. This option does not cause ripples
in the other dependent tables.

The NO ACTION rule is very very similar to the RESTRICT rule in effect.
There is one small difference but I don't recall what it is for DB2. Even
the DB2 manual doesn't make the distinction very clear.

DB2 doesn't have a SET DEFAULT rule. If I had to guess, I'd speculate that
it deletes the desired row from the DEPT table and then changes the values
of the D21 rows in the EMP table to a default department number, which was
presumably defined in the original CREATE TABLE statement. But that is
strictly a guess.

I hope this helps,

Rhino



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.6 - Release Date: 11/04/2005


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to