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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

<Ол>

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

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

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

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

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