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

Question

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

У Орена была хорошая запись , в которой была исправлена ​​проблема, но она закончилась:

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

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

Answer 1

Прочитайте книгу Скотта Амблера " Рефакторинг баз данных "; возьмите с собой щепотку соли, но там много хороших идей.

Сведения о доступных решениях зависят от используемой СУБД. Тем не менее, вы можете делать такие вещи, как:

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

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

Answer 2

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

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

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

Answer 3

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

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

Оставляя внешние детали на стороне (код, слои и т. Д.), Я попытаюсь немного объяснить, как мы в настоящее время управляем изменениями базы данных.

На данный момент у нас есть два правила, которым мы пытаемся следовать:

1. Во-первых, старый код (sql, хранимые процедуры, функции и т. Д.) Работает как есть и должен храниться как есть, не внося слишком много изменений, если только нет случая (ошибка или изменение функции), и Конечно, постарайтесь документировать это как можно больше (особенно такие проблемы, как: «WTF !, почему он сделал это вместо этого?»).

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

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

Рефакторинг базы данных - очень сложное поле, на которое нужно ответить коротким ответом. Есть много книг, которые отвечают на все ваши проблемы, одна http://databaserefactoring.com/ указана в одном из ответов .

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

Answer 4

Если предположить только 2 версии вашего клиента, я бы оставил только одну копию данных в новых таблицах.

Вы можете поддерживать контракт между старыми и новыми приложениями за представлениями поверх новых таблиц. Используйте до / вместо триггеров для обработки записей в «старые» представления, которые фактически записывают в новые таблицы.

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

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

Более 2 версий усложняются, как уже упоминалось ...