Официално нямате контрол върху реда на каскадните операции. Може да успеете да злоупотребите с някои недокументирани поведение обаче:
- за MySQL 5.5 външните ключове се изпълняват в реда, в който са създадени, така че отпадането и пресъздаването на
fk_category_org-ограничението трябва да работи - за MySQL 5.6+ външните ключове се изпълняват в лексикалния ред на имената им, така че преименуването на
fk_category_orgдо напр.fk_z_category_orgтрябва да работи
Това е недокументирано и може да се промени по всяко време (и може да бъде повлияно от други фактори).
Като се има предвид това, правилният начин да направите това (и всичко друго твърде сложно за on cascade ) би било да добавите before delete -задействане
във вашата organisation -таблица, която "ръчно" изтрива първо потребителите и след това категориите. before delete -тригерите се изпълняват преди on cascade (така че можете да решите дали искате да ги запазите или не, въпреки че вероятно ще бъде подвеждащо).
Не е напълно ясно дали това е вашето преднамерено поведение, но в момента потребителят може да има категория, която принадлежи към организация 1, докато е приписан към организация 2. Изтриването на организация 1 все още ще се провали. Изглежда малко така, сякаш това е, което искате да предотвратите чрез своя дизайн, но ако искате изтриването да работи и в този случай, вие трябва за да използвате спусъка, за да можете да го включите (или да го изтриете ръчно в приложението си), каскадирането няма да работи, освен ако не каскадирате и в таблицата с категории.
