Миграция данных из устаревшей структуры данных в новую структуру данных

редактировать: больше объяснений синхронизации с использованием двунаправленных триггеров; обновления для синтаксиса, языка и ясности.

преамбула

Я столкнулся с аналогичными проблемами при обновлении модели данных в большом веб-приложении, над которым я работал в течение 7 лет, поэтому я чувствую вашу боль. Из этого опыта, я бы предложил что-то немного другое - но надеюсь, что будет намного легче реализовать. Но сначала замечание:--3-->

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

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

• оперативные цели такие как выкатить новую услугу
• производительность отчета (вместо этого используйте материализованные представления, триггеры или пакетные задания)

эта структура будет меняться со временем, поэтому ваша архитектура должна допускать частые добавления и нечастые нормализации к ней. Это означает, что ваша структура данных и любые общие API к ней (включая службы RESTful) должны быть правильно версионными.

Почему веб-службы RESTful?

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

Я спрашиваю потому, что:

• вы теряете транзакции ACID (каждый вызов является одной транзакцией, если вы не реализуете некоторые ужасно сложные стандарты WS -*)
• снижение производительности: прямые подключения к базе данных будут быстрее (без веб-сервера работа и переводы) и имеют меньшую задержку (обычно 1 мс, а не 50-100 мс), которая будет заметно уменьшите отзывчивость в приложениях, написанных для прямых подключений к БД
• структура базы данных не абстрагируется от службы RESTful, поскольку вы признаете, что с нормализацией базы данных вам нужно переписать веб-службы и переписать вызывающие их приложения.

и другие сквозные проблемы без изменений:

• управляемость: прямые подключения к базе данных можно контролировать и управлять многими универсальными инструментами здесь
• безопасность: прямые соединения более безопасны, чем веб-службы, которые ваши разработчики напишут,
• авторизация: модель разрешений базы данных очень продвинутая и настолько мелкозернистая, насколько вы могли бы хотеть
• масштабируемость: веб-служба-это (только?) непосредственно подключенное приложение базы данных и поэтому масштабируется только как многое, как база данных

вы можете перенести базу данных и сохранить устаревшие приложения запущенными, поддерживая устаревший RESTful API. Но что, если мы можем сохранить устаревшие приложения без представляем услугу RESTful "legacy".

управление версиями базы данных

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

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

Это на самом деле довольно легко реализовать, но решает только отчетность и функциональность только для чтения. Как насчет устаревшего приложения DML? DML можно решить с помощью

• обновляемые представления для простых преобразований
• внедрение хранимых процедур где обновляемые представления невозможны (например, " вызов insert_emp (?, ?, ?)" а не "вставить в пуп (столбца col1, столбец col2, кол3) значения (?, ? ?)".
• есть "устаревшая" таблица, которая синхронизируется с новой базой данных с триггерами и ссылками БД.

наличие таблицы устаревшего формата с двунаправленной синхронизацией с таблицей (таблицами) нового формата с использованием триггеров является решением грубой силы и относительно уродливым.

вы получаете идентичные данные в двух разных схемах (или базы данных) и возможность выхода данных из синхронизации, если код синхронизации имеет ошибки - и тогда у вас есть классические проблемы проблемы "два мастера". Таким образом, рассматривайте это как последнее средство, например, когда:

• фундаментальная структура изменилась (например, изменение мощности отношения), или
• перевод в устаревший формат является сложной функцией (например, если устаревший столбец является квадратом значения столбца нового формата и установлен в "4", обновляемое представление не может определить, является ли правильное значение +2 или -2).

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

создание базы данных совместимости устаревшая структура с использованием описанных выше подходов сводит к минимуму изменения в устаревших приложениях (в некоторых случаях устаревшее приложение продолжает работу без каких-либо изменений кода). Это значительно снижает затраты на разработку и тестирование (для которых нет чистой функциональной выгоды для бизнеса) и значительно снижает риск развертывания.

Это также позволяет сосредоточиться на реальной ценности для организации:

• новая структура базы данных
• новый RESTful web services
• новые приложения (потенциально строить с помощью веб-служб RESTful)

положительный аспект веб-сервисов

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