Обновления схемы базы данных

Question

Я работаю над приложением AIR, которое использует локальную базу данных SQLite, и мне было интересно, как мне управлять обновлениями схемы базы данных при распространении новых версий приложения. Также учитывая обновления, которые пропускают некоторые версии. Например. вместо того, чтобы идти от 1,0 до 1,1, переходить от 1,0 до 1,5.

Какую технику вы бы порекомендовали?

Answer 1

В случае SQLite вы можете использовать прагму user_version для отслеживания версии базы данных. Чтобы получить версию:

PRAGMA user_version

Чтобы установить версию:

PRAGMA user_version = 5

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

Select Case currentUserVersion
Case 1
  // Upgrade to version 2
Case 2
  // Upgrade to version 3
Case etc...
End Select

Это позволяет приложению обновляться до самой последней версии независимо от текущей версии БД.

Answer 2

Мы записываем каждое изменение DDL в БД, и когда мы делаем «релиз», мы объединяем их в один сценарий «обновления» вместе со всеми хранимыми процедурами, которые изменились «с прошлого раза»

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

Каждая хранимая процедура находится в отдельном файле. Каждый из них начинается с оператора «insert» в таблице журналов, в которой хранятся имя SProc, версия и «сейчас». (На самом деле SProc выполняется для сохранения этого, это не необработанный оператор вставки).

Иногда во время развертывания мы вручную меняем SProc или коэффициенты развертывания из DEV, а сравнение журнала в клиентских базах данных TEST и PRODUCTION позволяет нам проверить, что все в одной версии.

У нас также есть основная база данных "release", к которой мы применяем обновления, и мы используем восстановленную резервную копию этой базы данных для новых установок (экономит время выполнения сценариев, которое, очевидно, увеличивается со временем). Мы обновляем это как & когда, потому что, очевидно, если оно немного устарело, можно применить более поздние патчи-сценарии.

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

SQL Server имеет кнопку на панели инструментов для написания сценария изменения, так что вы можете использовать инструменты GUI для внесения всех изменений, но вместо их сохранения вместо этого создайте сценарий. (на самом деле, есть флажок для всегда генерации скрипта, поэтому, если вы забудете и просто нажмете SAVE, он все равно даст вам скрипт, который он использовал после факта, который можно сохранить как файл патча)

Answer 3

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

Я собираюсь создать (SQL) сценарии, которые выполняют первоначальную настройку 1.0, а затем обновление с 1.0 до 1.1, 1.1 до 1.2 и т. Д.

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

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

Как я уже сказал: я рассматриваю это. Я, вероятно, начну реализовывать это завтра. Если вам интересно, я могу поделиться своим опытом. Я буду реализовывать это для приложения c #, которое использует LINQ-to-entity с SQL Server и MySQL в качестве СУБД.

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

EDIT: В ответе на другой вопрос здесь, на SO , я нашел ссылку на Migrator.Net. Я начал использовать его сегодня, и, похоже, это именно то, что я искал.

Answer 4

IMO самое простое, что нужно сделать, это обработать обновление, например, с. От 1,0 до 1,5 в виде последовательности обновлений от 1,0 до 1,1, от 1,1 до 1,2 и т. Д. Для каждого изменения версии сохраняйте сценарий преобразования / фрагмент кода.

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

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

Answer 5

У меня была такая же проблема в приложении .net, которое я писал.

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