DELETE avec contrainte sur table jointe sans déclencher de souci de clé étrangère

Bonjour tout le monde !

J’ai un cas que je n’avais pas encore rencontré jusqu’ici.

Soient deux tables a et b avec la clé étrangère de b dans a. Dans le cadre de migrations "inverses", je dois supprimer des enregistrements de b et donc avant cela les enregistrements liés de a. Du fait que les migrations se jouent sur plusieurs environnements, les IDs ne sont pas les mêmes sur chacun d’entre eux, je ne peux donc pas les mettre en dur. Par contre, j’ai une colonne qui elle sert justement à retrouver les mêmes données partout.

Dans l’idée de pré-nettoyer les données de A, je pensais naïvement faire DELETE a FROM a INNER JOIN b ON a.b_id = b.id WHERE b.out IN (…). Seulement, sur mon serveur, cela ne fonctionne pas parce qu’apparemment cela fait sauter la contrainte de clé étrangère entre les deux tables.
J’ai essayé avec une sous-requête, soit DELETE a FROM a WHERE a.b_id IN (SELECT id FROM b WHERE out IN (…)), mais cela pose le même problème.

Est-ce qu’il existe une solution avec une seule requête principale — évidemment sans désactiver ne serait-ce que temporairement la vérification des clés étrangères ?

Merci 

Tu peux nous donner le SGBD et le message d’erreur ?

Je rencontre l’erreur sous MySQL 5.7, mais les serveurs finaux sont en 5.6.

L’erreur est la suivante :

#1451 - Cannot delete or update a parent row: a foreign key constraint fails
    (`base`.`c`, CONSTRAINT `FK_46D8ACCCAD7076CA` FOREIGN KEY (`a_id`) REFERENCES `c` (`id`))

Edit

Gnééé

J’avais oublié que a était référencé dans c (erreur mise à jour)… Promis, ce soir, je dors.

Je pensais bien que le message d’erreur donnerait une piste : même Oracle est plutôt clair dans ces cas là (alors que c’est un spécialiste des messages à base de « erreur dans la requête au caractère 123 » sans plus de précision).

Je ne pratique pas Mysql, mais j’ai vu : 'On Delete Cascade' ; ça peut donner une 2ème piste si tu galères.

Le on delete cascade (supporté par tous les SGBD dignes de ce nom, même SQLite) est très pratique… et un peu casse-gueule si on ne fait pas attention : suppression de données qu’on aurait voulu conserver, suppression très longue parce que ça déclenche beaucoup de suppressions en cascade sur N niveaux… (dédicace à ce schéma de données de 800 tables qui avait des cascades partout et qui donc avait un peu de mal quand tu supprimais un objet-racine).

J’y avais pensé lors de la conception de la base, mais justement, on a des admins qui ne sont pas trop regardants, et c’est arrivé qu’ils suppriment des trucs sans where, et du coup s’il y a les comportements de cascade…