When to use "ON UPDATE CASCADE"

Question

Hi All,

I use "ON DELETE CASCADE" regular but never use "ON UPDATE CASCADE" as I am not so sure what situation it will be useful.

For the sake of discussion let see some code.

CREATE TABLE parent (
    id INT NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (id)
);

CREATE TABLE child (
    id INT NOT NULL AUTO_INCREMENT, parent_id INT,
    INDEX par_ind (parent_id),
    FOREIGN KEY (parent_id)
        REFERENCES parent(id)
        ON DELETE CASCADE
);

For "ON DELETE CASCADE", if a parent with an 'id' is deleted, a record in child with 'par_ind = id' will be automatically deleted. This should be no problem.

(1) This means that "ON UPDATE CASCADE" will do the same think when 'id' of the parent is updated?

(2) If (1) is true, It means that there is no need to use "ON UPDATE CASCADE" if 'parent.id' is not updatable (or will never be updated) like when it is 'AUTO_INCREMENT' or always set to be TIMESTAMP. Is that right?

(3) If (2) is not true, what other kind of situation we should use "ON UPDATE CASCADE".

(4) What if I (for some reason) update the 'child.parent_ind' to be something none exist, will it be automatically deleted.

Well, I know, some of the question above can be test programmically to understand but I want also know if any of this is Database vendor dependent or not.

Please shed some light.

Answer 1

It's true that if your primary key is just a identity value auto incremented, you would have no real use for ON UPDATE CASCADE.

However, let's say that your primary key is a 10 digit UPC bar code and because of expansion, you need to change it to a 13-digit UPC bar code. In that case, ON UPDATE CASCADE would allow you to change the primary key value and any tables that have foreign key references to the value will be changed accordingly.

In reference to #4--if you change the child ID to something that doesn't exist in the parent table (and you have referential integrity), you should get a foreign key error.

Answer 2

(1) Yes, it means that for example if you do UPDATE parent SET id = 20 WHERE id = 10 all children parent_id's of 10 will also be updated to 20

(2) If you don't update the field the foreign key refers to, this setting is not needed

(3) Can't think of any other use.

(4) You can't do that as the foreign key constraint would fail.

Answer 3

I think you've pretty much nailed the points!

If you follow database design best practices and your primary key is never updatable (which I think should always be the case anyway), then you never really need the ON UPDATE CASCADE clause.

Zed made a good point, that if you use a natural key (e.g. a regular field from your database table) as your primary key, then there might be certain situations where you need to update your primary keys. Another recent example would be the ISBN (International Standard Book Numbers) which changed from 10 to 13 digits+characters not too long ago.

This is not the case if you choose to use surrogate (e.g. artifically system-generated) keys as your primary key (which would be my preferred choice in all but the most rare occasions).

So in the end: if your primary key never changes, then you never need the ON UPDATE CASCADE clause.

Marc