Схема MySQL для синхронизации схемы через триггеры?

Question

Быстрое примечание: у меня есть 19 дней, чтобы выяснить проблемы моего клиента.

Справочная информация: Клиент нанял подрядчика, который хвастался, что он может получить новое приложение за дверь через 3 месяца. Через два месяца и несколько дней меня привели, и человека отпустили; нет полного кода, нет мыслей, вложенных в схему, и мерзость для пользовательского интерфейса.

У меня есть два приложения: одно производство и зрелое, а другое нуждается в любви. Один имеет все данные, которые мне нужны, а другой нет. Я пишу новый стиль кода TDD и нацеливаюсь на частично сфальсифицированную инфраструктуру SOA, которая охватывает все проблемы, кроме самих данных. Если бы у меня было больше времени, я мог бы использовать ликвидазу, чтобы преобразовать схемы в осколки мерзости (используйте ваше воображение), но я не... поэтому план Б следующий:

Приложение A (вставляет | обновляет | удаляет) сущность Foo, которая обновляет App ASchema.FooTable, которая через почтовый триггер обновляет AppBSchema.FooLikeTable и наоборот.

Я знаю, что это безумная идея, но это наименьшее из худших идей, которые у меня есть, мои опасения

1. Можно создать бесконечный цикл (триггер App A обновляет AppB, который обновляет AppA)
2. Там нет высокой нагрузки, но это в основном удваивает число операций до n*2, поэтому, если я достигну половины емкости сервера MySQL, кажется, что это будет эффективно на уровне или почти на полную мощность для базовых вещей, таких как обновление индексов и тому подобное.
3. Как смешанное благословение, разработчики оригинальных схем сделали все таблицы движком InnoDB... это ужасно для производительности, но может ли эта установка обеспечить более высокий шанс сохранения целостности.

Мой бюджет времени для реализации триггеров составляет 12 часов или перерыв.

Answer 1

Достаточно ли похожи AppASchema.FooTable и AppBSchema.FooLikeTable , чтобы вы могли переопределить один из них как обновляемое представление? Возможно, вам придется создать несколько дополнительных таблиц для хранения столбцов, которые являются уникальными для одной из схем приложения. Это было бы гораздо более приемлемым, чем куча триггеров.

Если нет, и вы должны реализовать это с помощью триггеров, вы правы, что вам нужно быть очень осторожным, чтобы убедиться, что нет рекурсивных зависимостей триггера. Если есть несколько таблиц, и они довольно похожи, это не будет слишком сложно. Если таблиц много или сходств мало, это займет время.