Oficialmente, no tienes control sobre el orden de las operaciones en cascada. Es posible que pueda abusar de algunos indocumentados comportamiento sin embargo:
- para MySQL 5.5, las claves foráneas se ejecutan en el orden en que se crearon, por lo que se eliminan y recrean
fk_category_org-la restricción debería funcionar - para MySQL 5.6+, las claves foráneas se ejecutan en el orden léxico de sus nombres, por lo que se cambia el nombre de
fk_category_orga por ej.fk_z_category_orgdebería funcionar
Esto no está documentado y puede cambiar en cualquier momento (y podría estar influenciado por otros factores).
Dicho esto, la forma correcta de hacer esto (y cualquier otra cosa demasiado complicada para on cascade ) sería agregar un before delete -activar
en su organisation -tabla que borra "manualmente" primero los usuarios y luego las categorías. before delete -los activadores se ejecutan antes de on cascade (para que pueda decidir si desea mantenerlos o no, aunque probablemente sería engañoso).
No está del todo claro si ese es su comportamiento previsto, pero actualmente, un usuario puede tener una categoría que pertenece a la organización 1 mientras está asignado a la organización 2. La eliminación de la organización 1 aún fallaría. Parece que eso es lo que quiere evitar con su diseño, pero si quiere que la eliminación funcione también en este caso, necesita para usar el disparador para poder incorporar eso (o eliminarlo manualmente en su aplicación), la cascada no funcionará a menos que también la cascada en la tabla de categorías.
