Offiziell haben Sie keine Kontrolle über die Reihenfolge der kaskadierten Operationen. Möglicherweise können Sie einige undokumentierte missbrauchen Verhalten jedoch:
- Für MySQL 5.5 werden die Fremdschlüssel in der Reihenfolge ausgeführt, in der sie erstellt wurden, also wird
fk_category_orggelöscht und neu erstellt -constraint sollte funktionieren - für MySQL 5.6+ werden die Fremdschlüssel in der lexikalischen Reihenfolge ihrer Namen ausgeführt, also
fk_category_orgumbenannt zu z.B.fk_z_category_orgsollte funktionieren
Dies ist nicht dokumentiert und kann sich jederzeit ändern (und kann durch andere Faktoren beeinflusst werden).
Abgesehen davon, der richtige Weg, dies zu tun (und alles andere, was zu kompliziert für on cascade ist ) wäre, einen before delete hinzuzufügen -Trigger
auf Ihre organisation -Tabelle, die "manuell" zuerst die Benutzer und danach die Kategorien löscht. before delete -Trigger werden vor on cascade ausgeführt (damit Sie entscheiden können, ob Sie diese behalten möchten oder nicht, obwohl es wahrscheinlich irreführend wäre).
Es ist nicht ganz klar, ob dies Ihr beabsichtigtes Verhalten ist, aber derzeit kann ein Benutzer eine Kategorie haben, die zu Organisation 1 gehört, während er Organisation 2 zugewiesen ist. Das Löschen von Organisation 1 würde dann immer noch fehlschlagen. Es sieht ein bisschen so aus, als ob Sie das durch Ihr Design verhindern möchten, aber wenn Sie möchten, dass das Löschen auch in diesem Fall funktioniert, müssen Sie es brauchen Um den Trigger zu verwenden, um dies zu integrieren (oder manuell in Ihrer Anwendung zu löschen), funktioniert die Kaskadierung nicht, es sei denn, Sie kaskadieren auch in der Kategorietabelle.
