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

Question

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

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: N.B. Схемы совершенно разные.

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

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

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

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

до

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

Answer 4

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

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

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

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

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