Syntaxe MySQL à la syncronisation de schéma via des triggers?

Question

Note rapide: J'ai 19 jours pour comprendre les problèmes de mon client.

Contexte: Le client a embauché un entrepreneur qui s'est vanté d'avoir pu obtenir une nouvelle application à la porte dans 3 mois. Deux mois et quelques jours plus tard, on m'a amené et l'individu a été laissé partir; il n'y a pas de code complet, pas de pensée mise dans le schéma, et une abomination pour une interface utilisateur.

J'ai deux applications: une production et mature et l'autre qui a besoin d'amour. On a toutes les données dont j'ai besoin et l'autre non. Je suis en train d'écrire un nouveau style de code TDD et de viser une infrastructure SOA partiellement truquée par un jury qui couvre toutes les questions, sauf les données elles-mêmes. Si j'avais plus de temps, je pourrais utiliser liquibase pour refactoriser les schémas en fragments d'abomination (utilisez votre imagination) mais je ne ... donc le plan B est comme suit:

App A (insère | met à jour | supprime) entité Foo qui met à jour AppASchema.FooTable qui via un post-trigger met à jour le AppBSchema.FooLikeTable et vice versa.

Je sais que c'est une idée folle mais son moindre des pires idées que j'ai, mes préoccupations sont

1. possible de créer une boucle sans fin (mises à jour de déclenchement AppA AppB qui met à jour APPA)
2. Il n'y a pas de charge élevée, mais cela double fondamentalement les ops à n * 2, donc si j'atteins la moitié de la capacité du serveur MySQL, il semblerait que ce soit effectivement ou presque. Comme une bénédiction mitigée, les concepteurs de schémas originaux ont fait toutes les tables InnoDB moteur ... c'est horrible pour la performance, mais cette configuration pourrait assurer une plus grande chance de garder l'intégrité.

Mon budget de temps pour implémenter les déclencheurs est de 12 heures ou d'un arrêt de buste.

Answer 1

AppASchema.FooTable Are et AppBSchema.FooLikeTable assez similaire que vous pouvez ré-écrire l'un d'entre eux comme updatable view? Vous devrez peut-être créer quelques tables supplémentaires pour contenir des colonnes propres à l'un des schémas d'application. Ce serait beaucoup plus facile à maintenir qu'un groupe de déclencheurs. Si ce n'est pas le cas, et que vous devez l'implémenter à l'aide de déclencheurs, vous avez raison de dire que vous devez être très prudent pour vous assurer qu'il n'y a pas de dépendances de déclenchement récursives. S'il y a une poignée de tables et qu'elles sont assez similaires, cela ne sera pas trop difficile. S'il y a beaucoup de tables ou si les similitudes sont rares, cela prendra du temps.