Officiellt har du ingen kontroll över ordningen för de kaskadoperationer. Du kanske kan missbruka några odokumenterade beteende dock:
- för MySQL 5.5 exekveras de främmande nycklarna i den ordning de skapades, så släpp och återskapa
fk_category_org-constraint borde fungera - för MySQL 5.6+ exekveras de främmande nycklarna i lexikal ordning efter deras namn, så byta namn på
fk_category_orgtill t.ex.fk_z_category_orgborde fungera
Detta är odokumenterat och kan ändras när som helst (och kan påverkas av andra faktorer).
Som sagt, det rätta sättet att göra detta (och allt annat som är för komplicerat för on cascade ) skulle vara att lägga till en before delete -trigger
på din organisation -tabell som "manuellt" tar bort användarna först och sedan kategorierna efteråt. before delete -triggers exekveras före on cascade (så du kan bestämma om du vill behålla dem eller inte, även om det förmodligen skulle vara missvisande).
Det är inte helt klart om det är ditt avsedda beteende, men för närvarande kan en användare ha en kategori som tillhör organisation 1 medan han är tilldelad organisation 2. Att ta bort organisation 1 skulle då fortfarande misslyckas. Det ser lite ut som om det är det du vill förhindra med din design, men om du vill att borttagningen ska fungera även i det här fallet, behöver om du vill använda triggern för att kunna införliva det (eller manuellt radera det i din applikation), kommer inte kaskad att fungera om du inte också kaskader i kategoritabellen.