Когда две базы данных имеют настолько радикально разные схемы, вам следует искать методы миграции или репликации данных, а не синхронизации. SQL Server предоставляет для этого две технологии: SSIS и репликацию, или вы можете написать свой собственный сценарий для этого.
Репликация берет новые или измененные данные из исходной базы данных и копирует их в целевую базу данных. Он предоставляет механизмы для планирования, упаковки и распределения изменений и может обрабатывать как обновления в реальном времени, так и пакетные обновления. Для работы ему необходимо добавить достаточно информации в обе базы данных, чтобы отслеживать изменения и совпадающие строки. В вашем случае было бы сложно определить, какие «Продукты» были изменены, поскольку вам нужно было бы идентифицировать все соответствующие измененные строки в 4 или более разных таблицах. Это можно сделать, но это потребует некоторых усилий. В любом случае вам придется создавать представления, соответствующие целевой схеме, поскольку репликация не позволяет преобразовывать исходные данные.
SSIS извлечет данные из одного источника, преобразует их и отправит в цель. В нем нет встроенных механизмов для отслеживания изменений, поэтому вам придется добавлять поля в свои таблицы для отслеживания изменений. Это строго пакетный процесс, который может выполняться по расписанию. Основное преимущество заключается в том, что вы можете выполнять широкий спектр преобразований, в то время как репликация практически не позволяет их (кроме рисования данных из представления). Вы можете создать потоки данных, которые изменяют только соответствующее поле продукта, когда изменяется запись атрибута, связанного с продуктом, или просто воссоздают всю запись продукта и перезаписывают целевую запись.
Наконец, вы можете создать свои собственные триггеры или хранимые процедуры, которые будут запускаться при изменении данных, и скопировать их из одной базы данных в другую.
Я также должен отметить, что вы, вероятно, чрезмерно нормализовали свою базу данных. Во всех трех случаях у вас будет некоторое снижение производительности, когда вы объедините все таблицы для воссоздания объекта, что приведет к большему количеству необходимых блокировок и неэффективному использованию индексов. Вы жертвуете производительностью и масштабируемостью ради простоты изменений.
Возможно, вам стоит взглянуть на функцию разреженных столбцов в SQL Server 2008, чтобы обеспечить поддержку гибких схем при сохранении производительности и масштабируемости.
person
Panagiotis Kanavos
schedule
13.07.2010
