Лучшая технология для синхронизации данных между различными схемами базы данных?

Question

У меня есть база данных SQL Server 2005, в которой работает наше приложение учета / инвентаризации. Мы планируем использовать новую платформу для онлайн-заказов, которая имеет собственную базу данных.

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

Итак, мой вопрос ... каков наилучший способ передачи данных назад и вперед между двумя базами данных, с разными схемами?

Тиражирование? SSIS? Что бы вы предложили и почему?

Любая помощь будет оценена!

Answer 1

Деловые правила - трудная часть

Односторонняя синхронизация? Двусторонняя синхронизация? Толчок в реальном времени? Ночные обновления? Сбросить и перезагрузить? Сравнить и обновить? Решение конфликта? Какая сторона выигрывает? Нажимать информацию только для чтения в одну сторону, а информацию заказа - в другую? А как насчет изменений / отмены / и т.д.? Получают ли статусы заказа сдвинуты назад?

Вы можете видеть, куда я иду. Технология является второстепенным вопросом.

Из-за проблемы бизнес-правил и из-за того, что две системы имеют разные схемы (и разные цели), это не стандартное перемещение данных, и большинство «стандартных» ответов (репликация, доставка журналов и т. Д.) со стола.

Существуют фреймворки, разработанные для этой цели, например Microsoft BizTalk или Scribe Insight . Хотя они громоздки и дороги.

Не так уж сложно создать собственную систему очереди, основанную на триггерах SQL или запланированных отправках (в зависимости от ваших потребностей) в C # или на вашем любимом языке. Это, вероятно, маршрут, по которому я бы пошел. Вероятно, потребуется третья база данных «передачи» для хранения очереди изменений, выполненных одной стороной, и модуль для применения бизнес-правил и передачи данных другой.

Answer 2

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

Answer 3

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

Для этого я бы, скорее всего, использовал SSIS. Довольно просто создать пакет преобразования и достаточно просто поддерживать.

Answer 4

Репликация работает хорошо, и если она двухсторонняя, это может быть единственным приемлемым вариантом, поскольку встроено разрешение конфликтов.

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

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