Копирование данных из локальной базы данных в удаленную.

Question

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

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

• Репликация, хотя она не идеальна, и мы не можем ожидать, что она будет поддерживаться в версии SQL, которую мы используем в размещенной среде.
• Связанный сервер, прямое копирование данных - медленный и несколько небезопасный метод
• Веб-сервисы для передачи данных
• Экспорт данных, которые нам требуются, в формате XML и передача на сервер для массового импорта.

Скопированные данные попадают в копии таблиц без полей идентификации, поэтому данные могут быть вставлены / обновлены без каких-либо нарушений в этом отношении. Эта передача данных не обязательно должна выполняться на уровне базы данных, это может быть сделано из .net или других средств.

Дополнительная информация

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

Количество записей, о которых мы говорим, составляет около 4000 строк на таблицу для основных таблиц (каталог продуктов) на данный момент, но это полностью зависит от клиента, на котором мы его развертываем, поскольку у каждого будет свой каталог продуктов. В диапазоне от 100 до 1000 продуктов. Чтобы уточнить, каждый клиент находится в отдельной комбинации локальной / размещенной базы данных, они не объединены в одну систему.

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

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

Answer 1

Ну, я пристрастен. Я должен признать. Я хотел бы загипнотизировать вас в обстрел SQL Compare для этого. Я сталкивался именно с такой проблемой во всей ее ужасной открытости. Я получил копию SQL Compare и никогда не оглядывался назад. SQL Compare - это на самом деле глупое название для программного обеспечения, которое синхронизирует базы данных. Оно также будет делать это из командной строки, как только вы получите рабочий проект со всеми правильными кнопками и кнопками. Конечно, вы можете сделать это только для достаточно небольших баз данных, но это действительно инструмент, без которого я бы не хотел, чтобы его видели на публике.

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

Answer 2

В итоге я выбрал набор триггеров для захвата изменений данных в таблице журнала изменений. Затем существует приложение, которое опрашивает эту таблицу и генерирует XML-файлы для отправки веб-службе, работающей в удаленном местоположении.

Answer 3

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

Массовые операции, вероятно, будут охватывать широкий спектр сценариев, и вы должны добавить это в начало списка.

Answer 4

Я бы порекомендовал использовать для этого службы преобразования данных (DTS). Вы можете создать пакет DTS для добавления и один для повторного создания данных.

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

Answer 5

Сколько данных вы говорите? Сколько существует «клиентских» БД? и как часто это должно происходить? Ответы на эти вопросы будут иметь большое значение на пути, по которому вы должны идти.