Перенос данных из структуры устаревших данных в новую структуру данных

Ответ 1

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

Преамбула

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

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

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

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

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

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

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

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

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

И другие сквозные проблемы не изменяются:

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

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

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

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

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

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

• Обновляемые представления для простых преобразований
• Представление хранимых процедур, в которых обновляемые представления невозможны (например, "CALL insert_emp (?,?,?)", а не "INSERT INTO EMP (col1, col2, col3) VALUES (?,??)".
• У вас есть таблица "legacy", которая синхронизируется с новой базой данных с триггерами и связями DB.

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

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

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

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

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

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

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

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

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

Ответ 2

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

Параллельно вам нужно определить, что представляет собой (cernrralized) legacy db api и сопоставить его с вашей нормализованной моделью. Теперь, на досуге, замените оригинальные вызовы db legs на вызовы API db legacy. Это не прерывает код.

Как только исходные вызовы будут полностью заменены, вы можете переключить модель данных на реальный нормализованный. Это не должно нарушать код, поскольку теперь все идет против устаревшего API-интерфейса db или нормализованного API-интерфейсов.

Наконец, вы можете заменить устаревшие вызовы API-интерфейсов db и связанный с ним код с пересмотренным кодом, который использует нормализованный API данных. Это требует тщательной перекодировки.

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

В этом документе есть хороший обзор: http://se-pubs.dbs.uni-leipzig.de/files/Cleve2006CotransformationsinDatabaseApplicationsEvolution.pdf

Ответ 3

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

Во-первых, усилия по изменению клиентских приложений будут значительными - если базовый домен изменится (например, внедрив концепцию адреса, который отдельно от человека), клиентские приложения также меняются - это не просто изменение способа доступа к данным. Лучший способ избежать этой боли - написать свой уровень API, чтобы отразить модель бизнес-домена будущего, и приклеить к ней свою прежнюю схему базы данных; если есть новые концепции, которые вы не можете отразить с использованием старых данных (например, "get/app/addresses/addressID" ), выбросьте ошибку NotImplemented. Если вы можете отразить новую модель со старыми данными, соедините ее как можно лучше, а затем перегруппируйте под обложками.

Во-вторых, это означает, что вам необходимо создать управление версиями в вашем API как первоклассную проблему, поэтому вы можете сказать клиентам, что в версии 1 функции x, y и z выбрасывают исключения NotImplemented. Каждая версия должна быть обратной совместимости, но добавлять новые функции. Таким образом, вы можете реорганизовывать функции в версии 1 до тех пор, пока вы не нарушаете сервис, и реализуете функцию x в версии 1.1, функцию y в версии 1.2 и т.д. В идеале, есть дорожная карта для ваших версий и уведомлять клиентское приложение владельцам, если вы собираетесь прекратить поддерживать версию или освободить изменение.

В-третьих, набор автоматических интеграционных тестов для вашего API - лучшая инвестиция, которую вы можете сделать - они подтверждают, что вы не нарушили функции в качестве рефакторинга.

Надеюсь, что это будет полезно - я не думаю, что на ваш вопрос есть один простой ответ.