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

Исходные данные в бэкэнд-системе сильно нормализованы, с десятками таблиц и ограничениями внешнего ключа. Это хорошо разработанная система СУБД OLTP. Многие из рассматриваемых таблиц содержат миллионы строк. Необходимо регулярно передавать эти данные в другие базы данных. Так часто, как это возможно; задержка может быть допущена. Прежде всего, максимальное время безотказной работы как внутренней, так и удаленной баз данных является обязательным условием.

Я использую SQL Server и знаком с отслеживанием изменений, изменением строк, триггерами и так далее. Я знаю, что Microsoft активно использует репликацию, SyncFx и SSIS для этих сценариев. Однако между техническими документами поставщиков и обзорами, рекомендующими технологии, и фактической реализацией, развертыванием и обслуживанием решения существует существенная разница. В мире SQL Server репликация часто рассматривается как решение «под ключ», но я пытаюсь найти альтернативные решения. (Есть некоторые опасения, что репликацию сложно администрировать, что затрудняет изменение схемы, и в случае, когда когда-либо потребуется повторная инициализация, для критических систем будут большие простои.)

Есть много ошибок. Из-за сложных взаимосвязей внешних ключей между большим количеством таблиц определение порядка выполнения захвата или применения обновлений не является тривиальным. Из-за уникальных индексов две строки могут быть заблокированы таким образом, что обновление по одной строке даже не будет работать (необходимо выполнить промежуточные обновления для каждой строки перед окончательным обновлением). Это не обязательно ограничители показа, поскольку уникальные индексы часто можно изменить на обычные, а внешние ключи можно отключить (хотя отключение внешних ключей крайне нежелательно). Часто вы услышите, что «просто» используете отслеживание изменений SQL 2008 и SSIS или SyncFx. Такие ответы на самом деле не соответствуют практическим трудностям. (И, конечно, клиентам действительно трудно понять, как копирование данных может быть настолько сложным, что еще больше осложняет ситуацию!)

Эта проблема в конечном итоге очень общая: выполнить одностороннюю синхронизацию многих тесно связанных таблиц базы данных с большим количеством строк. Почти каждый, кто связан с базами данных, имеет дело с этим видом проблемы. Белые книги распространены, практический опыт трудно найти. Мы знаем, что это может быть трудной проблемой, но работа должна быть выполнена. Давайте послушаем, что сработало для вас (и чего следует избегать). Расскажите о своем опыте использования продуктов Microsoft или продуктов других поставщиков. Но если вы лично не испытывали в бою решение с большим количеством тесно связанных таблиц и строк, воздержитесь от ответа. Давайте будем практичными, а не теоретическими.