Синхронизация данных приложения - запуск нового приложения в сочетании с устаревшим

Question

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

Новая система - это ASP.NET, а устаревшая - VB6.Оба работают в базе данных SQL Server.На данный момент неясно, будут ли базы данных находиться в одной серверной комнате, не говоря уже об одной и той же стране.

На данный момент на столе находятся два решения:

1. Веб-службы, которые находятся на каждом компьютере и вызываются другим приложением.
   • Нужно изменить метод сохранения в базовом классе (классах?) для собственных объектов.Это инвазивно и может стать проблемой, когда дело доходит до его отключения.

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

   • Необходимо изменить схемы в обоих приложениях, чтобы убедиться, что у них есть LastModified (DateTime) во всех таблицах, чтобы мы могли выполнять периодический ВЫБОР с любым заданным интервалом.

Оба решения кажутся разумными.Оба решения имеют свои плюсы и минусы.Бизнес запросил задержку не более чем на 2 секунды (!) между обновлением одной системы и просмотром ее в другой.Возможно, это слишком растянутая цель, но это то, к чему нужно стремиться.

Другими, которые были предложены, но отвергнуты (я готов пересмотреть), являются:

• Триггеры базы данных (blugrh)
• BizTalk или другая шина (похожа на кувалду и слишком сложна для решения по переключению)
• Изменение всех хранимых процедур (нееет.)
• SSIS (пока недостаточно знаю об этом)

Цените любые мысли, которые у вас могут возникнуть.

Редактировать:Н.Б.Схемы совершенно разные.

Answer 1

В конце концов, это было решено с помощью веб-сервиса.Это сработало действительно хорошо.

Answer 2

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

Используют ли базы данных одну и ту же структуру?Если это так, я бы посмотрел на реализацию репликации.

Редактировать

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

1. Измените параметры хранения данных В приложении, чтобы выполнять вставки / обновления / удаления в обеих таблицах.Преимущество:Немедленный, без каких-либо внешних процессов для совместного использования.Недостаток:приходится изменять весь код, жестко отключать и т.д.

2. Создайте приложение синхронизации, как вы упомянули, для синхронизации измененных данных.Преимущество:можно просто отключить после завершения передачи.Недостаток:очень сложный в написании, особенно при наличии большого количества таблиц.Кроме того, не так быстро, 2 секунды будет ОЧЕНЬ трудно выполнить

Answer 3

Лично я бы отверг идею о том, чтобы пользователи использовали обе системы одновременно.Как вы собираетесь решить проблему, если пользователь 1 изменил запись 1 в системе 1, а пользователь 2 изменил запись 1 другим способом в системе 2?

Кроме того, если вы не требуете, чтобы люди использовали новую систему, они этого не сделают.Сопротивление переменам очень, очень сильно в большинстве организаций.

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

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

Иногда вам просто приходится давать отпор, когда пользователи бизнеса хотят чего-то неразумного.

Answer 4

То, что вы здесь описываете, заставляет меня чувствовать себя как в кошмарном сне!Я думаю, вам следует сначала разъяснить всем, что невозможно (или, по крайней мере, чрезвычайно дорого) думать о том, чтобы позволить пользователям обновлять все данные через 2 разных приложения с 2 разными базами данных в течение всего процесса перехода!Я даже не говорю о задержке в 2 секунды ...

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

(кстати, этот метод также заставит пользователей постепенно переходить на новую версию, избегая ожидаемая и раздражающая проблема с сопротивлением, уже выявленная @HLGEM)

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

1. Установите все процедуры, позволяющие переносить данные из устаревшей базы данных в новую.Я предполагаю, что вам нужно будет запустить их несколько раз в ближайшие месяцы...
2. Установите все процедуры, позволяющие передавать данные другим способом (обратная передача данных).
3. Здесь вы должны были определить однородные группы таблиц, которые можно перемещать вместе.Объедините предыдущий код таким образом, чтобы вы получили для каждой из этих групп процедуру "передачи данных" и процедуру "обратной передачи".

Затем для каждой из этих групп

4. Установите ограничения на обновление с помощью кода или на уровне базы данных
5. Запустите свою процедуру "передачи данных"
6. Организуйте процедуру "обратного переноса" в качестве триггера в новой базе данных

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

Работая таким образом, вы постепенно перейдете от ситуации, когда у вас есть

• устаревшее приложение для чтения / записи + доступно только для чтения новое приложение

Для

• устаревшее приложение только для чтения + чтение / запись новое приложение.