Как поддерживать структуру базы данных в веб-приложении?

Question

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

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

Я использовал для хранения таблицы с текущей версией базы данных в базе данных. Затем каждое обновление представляло собой файл SQL, который выполнял свою работу - создавал новую таблицу, добавлял столбец или перемещал данные. Файлы были названы в честь этих версий - поэтому, если мой скрипт обновления получил версию базы данных 10, он просто перенес все файлы с 11.sql на N.sql и применил каждый из них, увеличивая номер версии базы данных одновременно.

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

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

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

Answer 1

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

Хранение отдельных версий скриптов, IMHO, не только хорошо для развертывания, но и для предоставления элементов, которые можно проверить в системе контроля версий.

Answer 2

Во-первых, мы представили таблицу версий схемы, которая отслеживает номер версии приложения, для которого установлена ​​схема, и мы отслеживаем версию каждой отдельной таблицы. у нас есть версия схемы, которую мы жестко запрограммировали в приложении, чтобы сравнить с этой версией приложения. Мы не хотим, чтобы приложение обращалось к неправильной версии БД. затем у нас есть набор сценариев для каждой таблицы, который мигрирует из предыдущей версии таблицы в текущую версию. Затем у нас есть целевая таблица, которую мы встраиваем в приложение, чтобы узнать, какая версия каждой таблицы ожидается в новой версии, чтобы узнать, соответствует ли она всем. если нет, то мы применяем различные сценарии миграции к схеме, чтобы привести db в порядок.

сложно? в некотором роде. спасение жизни. abosolutely. нет ничего лучше погони за ошибками в приложении, потому что схема неверна.

Answer 3

Многие фреймворки используют концепцию «миграций» - сценариев, которые обновляют схему вашей базы данных с одной ревизии до следующей более высокой ревизии. Точно так же, как правило, полезно иметь скрипт перехода на более раннюю версию, если вам необходимо отменить изменение. Иногда эти сценарии написаны на SQL, иногда они абстрагированы (например, Ruby on Rails). Вы можете создать эти сценарии вручную или использовать такой инструмент, как SQL Compare, о котором упоминали другие.

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

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

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

Answer 4

Возможно, вам следует прочитать статью, которую Этвуд писал о контроле версий БД о ужасах кодирования некоторое время назад: Ваша база данных находится под контролем версий?

Answer 5

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

Когда мы обновляем сайт, новые скрипты обнаруживаются и запускаются. Это имеет преимущество перед таким инструментом, как SQL Compare (который мне очень нравится), потому что мы можем делать одноразовые модификации данных. Однако мы запускаем SQL Compare и SQL Data Compare (для выбранных таблиц) после обновления, чтобы убедиться, что процедура работает правильно. После успешного запуска вся операция фиксируется, и база данных обновляет информацию «run scripts», чтобы эти сценарии больше не запускались.

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

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

Answer 6

Вы должны посмотреть на инструмент под названием Powerdesigner. Вы можете загрузить 15-дневную полнофункциональную пробную версию. Это поможет вам моделировать, держать изменения в актуальном состоянии и т.д.

Это отличный инструмент для выполнения ваших задач и многое другое.

Answer 7

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

Параллельно я поддерживаю модель базы данных (я использую Azzurri Clay в Eclipse), чтобы я мог восстановить свою модель в любое время. Любые необходимые изменения сначала вносятся в модель, а затем обновляются примечания к выпуску. Аззурри не может генерировать изменения, но только создает.

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

Answer 8

Используйте инструмент типа RedQate SQLCompare или xSQL Object от xSQL Software, чтобы генерировать ваши diff / delta T-SQL скрипты на лету.

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

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

Вот и все в двух словах.