Вам понадобится флаг для записи записей, которые нужно синхронизировать. Мы используем такую систему, в которой каждая таблица для синхронизации имеет столбец, который хранит синхронизацию. Когда запись изменяется, она также изменяет свое состояние (в триггере), а инструмент синхронизации запрашивает измененные записи каждые несколько минут.
Недостатком является то, что вам понадобится много кода, чтобы справиться с этим правильно, особенно потому, что вы не можете удалять записи напрямую. Инструмент синхронизации сначала должен знать и должен выполнять фактическое удаление. Кроме того, сложно построить хорошую очередь таким образом, поэтому, если записи синхронизируются перед их родителями, вы получите сообщение об ошибке. И каждая таблица, которая должна быть синхронизирована, нуждается в дополнительной колонке.
Итак, теперь есть новое решение, которое должно быть реализовано. Это решение использует отдельную таблицу для очереди. Очередь содержит указатели на записи в других таблицах (значение первичного ключа и ссылка на имя таблицы/имя поля). Эта очередь теперь является единственной таблицей для мониторинга изменений, поэтому все, что нужно сделать таблице, это реализовать один триггер, который помечает измененные записи как измененные в очереди. Поскольку это отдельная очередь в отдельной таблице, это добавляет решения для проблем, о которых я упоминал ранее:
- Записи могут быть немедленно удалены. Инструмент синхронизации находит идентификатор в очереди, проверяет, что он больше не существует, поэтому он также удаляет его из другой базы данных.
- Родительские зависимости ребенка автоматически решаются. Новый родитель будет находиться в очереди перед его дочерними элементами, а удаленный родитель будет там позади своих детей. Единственная проблема, которую вы можете найти в перекрестных ссылках, хотя отложенные коммиты могут быть решением для этого.
- Нет необходимости в дополнительной колонке во всех таблицах. Только одна очередь, некоторые вспомогательные таблицы и один триггер, содержащий один вызов функции для каждой таблицы для синхронизации.
К сожалению, мы не полностью реализовали это решение, поэтому я не могу сказать вам, будет ли он эффективно работать лучше, хотя тесты определенно предлагают это.
Помните, что эта система делает один на одной копии записей. Я думаю, что это лучший подход. Скопируйте данные, а затем (затем) обработайте их на целевом сервере. Я не думаю, что это хорошая идея для обработки данных при копировании. Если что-то пойдет не так, у вас будет адская работа, отладка и восстановление/пересчет данных.
[Репликация MySQL] (http://dev.mysql.com/doc/refman/5.5/en/replication.html) - это то, что вам нужно? – Nemoden
@Nemoden не совсем. Хотя мы надеемся, что большая часть данных будет в аналогичных форматах, эти базы данных были разработаны по разным причинам (hr vs finance vs internet directory), поэтому мне нужно будет добавить несколько правил, по которым данные идут туда. Я бы хотел сделать некоторые вещи на уровне базы данных, если они достаточно похожи, но материал на базе SQL Server будет не таким простым, отчасти потому, что поля не всегда одинаковы и т. Д., Также если бы я был в php, я мог бы изменить эти правила проще или добавить проверку (например, отправку электронной почты) при записи попытки изменения информации. – Sean