Zusammenfassung dessen, was ich bisher gesehen habe:
- Manche Leute mögen Kaskadierung überhaupt nicht.
Cascade Delete
- Cascade Delete kann sinnvoll sein, wenn die Semantik der Beziehung ein exklusives "ist Teil von beinhalten kann " Beschreibung. Beispielsweise ist ein OrderLine-Datensatz Teil seiner übergeordneten Bestellung, und OrderLines werden niemals von mehreren Bestellungen geteilt. Wenn die Order verschwinden würde, sollte dies auch die OrderLine tun, und eine Zeile ohne Order wäre ein Problem.
- Das kanonische Beispiel für Cascade Delete ist SomeObject und SomeObjectItems, wo es keinen Sinn macht, dass ein Elementdatensatz jemals ohne einen entsprechenden Hauptdatensatz existiert.
- Das sollten Sie nicht Verwenden Sie Cascade Delete, wenn Sie den Verlauf beibehalten oder ein "weiches/logisches Löschen" verwenden, bei dem Sie nur eine gelöschte Bitspalte auf 1/true setzen.
Cascade-Update
- Cascade Update kann sinnvoll sein, wenn Sie tabellenübergreifend einen echten Schlüssel anstelle eines Ersatzschlüssels (Identitäts-/Autoincrement-Spalte) verwenden.
- Das kanonische Beispiel für Cascade Update ist, wenn Sie einen veränderlichen Fremdschlüssel haben, wie einen Benutzernamen, der geändert werden kann.
- Das sollten Sie nicht Verwenden Sie Cascade Update mit Schlüsseln, die Identitäts-/Autoincrement-Spalten sind.
- Cascade Update wird am besten in Verbindung mit einer eindeutigen Einschränkung verwendet.
Wann Kaskadierung verwendet werden sollte
- Möglicherweise möchten Sie eine besonders starke Bestätigung vom Benutzer zurückerhalten, bevor Sie eine Kaskadierung einer Operation zulassen, aber das hängt von Ihrer Anwendung ab.
- Cascading kann Sie in Schwierigkeiten bringen, wenn Sie Ihre Fremdschlüssel falsch einrichten. Aber du solltest okay sein, wenn du das richtig machst.
- Es ist nicht ratsam, Kaskadierung zu verwenden, bevor Sie sie nicht gründlich verstanden haben. Es ist jedoch eine nützliche Funktion und es lohnt sich daher, sich die Zeit zu nehmen, sie zu verstehen.
