Vous pourriez faire en sorte que la gâchette de A fasse quelque chose pour alerter la gâchette de B qu'elle n'a pas besoin de se déclencher. Il existe plusieurs souhaits pour configurer un état pour une session. L'approche la plus simple possible serait de faire quelque chose comme créer un package avec une variable booléenne bypass_checks_on_b que vous définissez sur TRUE avant de faire la UPDATE sur A, mis à FALSE une fois la UPDATE se termine, puis vérifiez l'état de cette variable dans votre déclencheur sur B avant de faire vos validations. Vous pouvez faire quelque chose de similaire avec une table temporaire ou un contexte plutôt que d'utiliser un package. Moins efficacement, vous pourriez potentiellement analyser la pile d'appels à l'intérieur de votre déclencheur sur B pour voir si le déclencheur sur A est dans la pile d'appels, mais cela aurait tendance à être plutôt moche.
Je serais très prudent à propos de toute cette architecture, cependant. Lorsque vous constatez que vous avez des déclencheurs sur A qui déclenchent des déclencheurs sur B qui voudraient interroger A, il est presque toujours vrai que vous avez mis beaucoup trop de logique dans les déclencheurs et que vous seriez bien mieux servi en déplaçant cette logique dans une couche de procédure stockée qui peut être appelée plutôt que les applications effectuant des insertions ou des mises à jour directes. Lorsque vous poussez trop de logique dans les déclencheurs, vous vous retrouvez avec un système très difficile à comprendre car il n'est pas évident, en regardant le code de l'application, quel type d'effets secondaires ont les différentes instructions. Et vous vous retrouvez avec un code très dynamique où vous avez de nombreux chemins à travers un seul morceau de code en fonction de l'appelant. Cela signifie presque certainement qu'il y aura des états que vous ne testez pas ou auxquels vous ne pensez pas où vous découvrirez que votre code fait quelque chose d'inattendu. Entre avoir une tonne d'états et avoir une base de code avec une tonne d'effets secondaires, vous pouvez très rapidement créer une base de code qui est essentiellement non maintenable.
