Синхронизация данных приложения - запуск нового приложения в сочетании с устаревшим
-
07-07-2019 - |
Вопрос
Мы находимся в процессе замены устаревшей системы.Пройдет некоторое время, пока оба приложения будут работать в тандеме.Пользователи смогут использовать любую систему, и задача состоит в том, чтобы иметь возможность синхронизировать свои базы данных друг с другом.
Новая система - это ASP.NET, а устаревшая - VB6.Оба работают в базе данных SQL Server.На данный момент неясно, будут ли базы данных находиться в одной серверной комнате, не говоря уже об одной и той же стране.
На данный момент на столе находятся два решения:
- Веб-службы, которые находятся на каждом компьютере и вызываются другим приложением.
- Нужно изменить метод сохранения в базовом классе (классах?) для собственных объектов.Это инвазивно и может стать проблемой, когда дело доходит до его отключения.
Единая служба Windows, которая опрашивает каждую базу данных и определяет, что изменилось, и пересылает адаптированные обновления по мере необходимости.
- Необходимо изменить схемы в обоих приложениях, чтобы убедиться, что у них есть LastModified (DateTime) во всех таблицах, чтобы мы могли выполнять периодический ВЫБОР с любым заданным интервалом.
Оба решения кажутся разумными.Оба решения имеют свои плюсы и минусы.Бизнес запросил задержку не более чем на 2 секунды (!) между обновлением одной системы и просмотром ее в другой.Возможно, это слишком растянутая цель, но это то, к чему нужно стремиться.
Другими, которые были предложены, но отвергнуты (я готов пересмотреть), являются:
- Триггеры базы данных (blugrh)
- BizTalk или другая шина (похожа на кувалду и слишком сложна для решения по переключению)
- Изменение всех хранимых процедур (нееет.)
- SSIS (пока недостаточно знаю об этом)
Цените любые мысли, которые у вас могут возникнуть.
Редактировать:Н.Б.Схемы совершенно разные.
Решение 4
В конце концов, это было решено с помощью веб-сервиса.Это сработало действительно хорошо.
Другие советы
2 секунды - это действительно сжатые сроки, и я предполагаю, что ваше решение для приложений Windows просто может не уложиться в них, особенно если одновременно вносятся сотни изменений или что-то еще, а время опроса должно составлять почти каждую секунду, чтобы надеяться уложиться в 2.
Используют ли базы данных одну и ту же структуру?Если это так, я бы посмотрел на реализацию репликации.
Редактировать
После комментария и добавления о том, что схемы совершенно разные, я должен сказать, что на самом деле я вижу два набора операций.
Измените параметры хранения данных В приложении, чтобы выполнять вставки / обновления / удаления в обеих таблицах.Преимущество:Немедленный, без каких-либо внешних процессов для совместного использования.Недостаток:приходится изменять весь код, жестко отключать и т.д.
Создайте приложение синхронизации, как вы упомянули, для синхронизации измененных данных.Преимущество:можно просто отключить после завершения передачи.Недостаток:очень сложный в написании, особенно при наличии большого количества таблиц.Кроме того, не так быстро, 2 секунды будет ОЧЕНЬ трудно выполнить
Лично я бы отверг идею о том, чтобы пользователи использовали обе системы одновременно.Как вы собираетесь решить проблему, если пользователь 1 изменил запись 1 в системе 1, а пользователь 2 изменил запись 1 другим способом в системе 2?
Кроме того, если вы не требуете, чтобы люди использовали новую систему, они этого не сделают.Сопротивление переменам очень, очень сильно в большинстве организаций.
Вместо этого я бы посоветовал вам внедрить новую систему и потребовать, чтобы все ее использовали, и ежечасно отправлять данные в старую систему на случай, если вам потребуется вернуться по какой-либо причине.
Я не вижу разумного способа получить 2-секундную синхронизацию.Это нелепое требование, и об этом следует недвусмысленно сообщить деловой стороне.
Иногда вам просто приходится давать отпор, когда пользователи бизнеса хотят чего-то неразумного.
То, что вы здесь описываете, заставляет меня чувствовать себя как в кошмарном сне!Я думаю, вам следует сначала разъяснить всем, что невозможно (или, по крайней мере, чрезвычайно дорого) думать о том, чтобы позволить пользователям обновлять все данные через 2 разных приложения с 2 разными базами данных в течение всего процесса перехода!Я даже не говорю о задержке в 2 секунды ...
По моему мнению, основная стратегия должна заключаться в постепенном переносе прав и возможностей обновления данных с устаревшего на новое приложение.Пользователи смогут видеть данные с обеих сторон, но обновлять их смогут только через одно из приложений.
(кстати, этот метод также заставит пользователей постепенно переходить на новую версию, избегая ожидаемая и раздражающая проблема с сопротивлением, уже выявленная @HLGEM)
Как только это правило будет четко принято, вы сможете выполнить следующие шаги.
- Установите все процедуры, позволяющие переносить данные из устаревшей базы данных в новую.Я предполагаю, что вам нужно будет запустить их несколько раз в ближайшие месяцы...
- Установите все процедуры, позволяющие передавать данные другим способом (обратная передача данных).
- Здесь вы должны были определить однородные группы таблиц, которые можно перемещать вместе.Объедините предыдущий код таким образом, чтобы вы получили для каждой из этих групп процедуру "передачи данных" и процедуру "обратной передачи".
Затем для каждой из этих групп
- Установите ограничения на обновление с помощью кода или на уровне базы данных
- Запустите свою процедуру "передачи данных"
- Организуйте процедуру "обратного переноса" в качестве триггера в новой базе данных
Я предполагаю, что первым видом данных, которые вы сможете передать, будут списки, которые не содержат никаких внешних ключей.
Работая таким образом, вы постепенно перейдете от ситуации, когда у вас есть
- устаревшее приложение для чтения / записи + доступно только для чтения новое приложение
Для
- устаревшее приложение только для чтения + чтение / запись новое приложение.