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

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

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

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

  1. Web services that sit on each machine and is called by the other application.
    • Need to modify the Save method on the base class(es?) for the native objects. This is invasive and could be a problem when it comes to switching it off.
  2. Единая служба Windows, которая опрашивает каждую базу данных и определяет, что было изменено, и при необходимости пересылает адаптированные обновления.

    • Need to change the schemas in both applications to ensure that they have a LastModified (DateTime) on all tables so we can do a periodic SELECT at any given interval.

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

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

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

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

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


person Iain Holder    schedule 07.11.2008    source источник


Ответы (4)


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

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

Изменить

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

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

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

person Mitchel Sellers    schedule 07.11.2008
comment
Схемы совершенно разные, поэтому будут преобразования данных. - person Iain Holder; 07.11.2008

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

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

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

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

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

person HLGEM    schedule 07.11.2008

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

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

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

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

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

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

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

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

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

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

to

  • устаревшее приложение только для чтения + новое приложение для чтения и записи.
person Philippe Grondier    schedule 14.11.2008

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

person Iain Holder    schedule 14.01.2009