▲ | SoftTalker 7 months ago | |||||||||||||||||||||||||||||||||||||||||||
You really shouldn’t be updating primary key values though. | ||||||||||||||||||||||||||||||||||||||||||||
▲ | magicalhippo 7 months ago | parent [-] | |||||||||||||||||||||||||||||||||||||||||||
While I overall agree, there have been cases where I have found it handy. In one case, we had a table of invoices and a table of goods items, and each goods item should point to an invoice. If one wants to use the natural key, invoice number, and have a foreign key to ensure the goods items can't point to an invoice that doesn't exist, then ON UPDATE CASCADE was needed in case the user had to change the invoice number (due to mistyping it or similar). Of course, if one does not use a natural key then this isn't such an issue. Another case was where we've had to merge databases after two companies merged. If they had overlapping primary key ranges, then the easiest was to switch to ON UPDATE CASCADE and then renumber the existing rows before inserting the other rows. We'd change back after the merge though. | ||||||||||||||||||||||||||||||||||||||||||||
|