Что является лучшими практиками для сценариев базы данных под управлением кодом

После нескольких повторений подход, который мы проявили, примерно был похож на это:

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

файл для таблицы запускается с команды CREATE, и последовательность ИЗМЕНЯЮТ команды, добавленные, поскольку схема развивается. Каждая из этих команд заключается в скобки в тестах для того, существуют ли таблица или столбец уже. Это означает, что каждый сценарий может быть выполнен в актуальной базе данных и ничего не изменит. Это также означает, что для любой старой базы данных, сценарий обновляет его к последней схеме. И для пустой базы данных СОЗДАТЬ сценарий составляет таблицу, и ИЗМЕНИТЬ сценарии все пропускаются.

у Нас также есть программа (записанный в Python), который сканирует каталог, полный сценариев, и собирает их в к одному большому сценарию. Это анализирует SQL как раз, чтобы вывести зависимости между таблицами (на основе ссылок внешнего ключа) и заказать им соответственно. Результатом является сценарий SQL монстра, который получает базу данных до спецификации сразу. Собирающая сценарий программа также вычисляет хеш MD5 входных файлов и использование, что для обновления номера версии, который записан в в специальную таблицу в последнем сценарии в списке.

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

Существует интересная статья в этой ссылке: https://blog.codinghorror.com/get-your-database-under-version-control /

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

Хранилище опции

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

Профессионалы: Полностью автоматизированная, тестируемая процедура обновления

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

Я склонен регистрироваться в начальной букве, создают сценарий. У меня тогда есть таблица DbVersion в моей базе данных и моем использовании кода что обновить базу данных по начальному соединению при необходимости. Например, если моя база данных будет в версии 1, и мой код в версии 3, мой код применит операторы ALTER для обеспечения его к версии 2, то к версии 3. Я использую простой fallthrough оператор переключения для этого.

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

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

Вы могли получить некоторые подсказки путем чтения, как это сделано с миграции Ruby on Rails . Лучший способ понять это состоит в том, чтобы, вероятно, просто попробовать его самостоятельно, и затем осмотр базы данных вручную.

Ответы на каждый из Ваших факторов:

• Хранилище СОЗДАЮТ сценарии. Если бы Вы хотите к версии контроля x.y.z тогда, было бы хорошо просто выполнить Ваш создавать сценарий для установки базы данных сразу. Вы могли добавлять ИЗМЕНИТЬ сценарии также для движения от предыдущей версии до следующего (например, Вы фиксируете версию 3, которая содержит версию 3, СОЗДАЮТ сценарий и версию 2 → 3 изменяют сценарий).
• Посмотрите решение для миграции направляющих. В основном они сохраняют число версии таблицы table version в базе данных, таким образом, Вы всегда знаете.
• Использование СОЗДАЮТ сценарии.
• Используя номера версий, вероятно, было бы самое универсальное решение — названия сценария и пути могут изменяться со временем.

Мои два цента!

Создать опция сценария:

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

методы управления стандартной версией Использования для хранения перейдите, отметьте версии и просмотрите истории объектов.

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

Профессионалы: Изменения в файлах прослежены в стандартном исходном коде как способ

Недостатки: Зависимость от ручного использования стороннего инструмента, чтобы сделать фактические обновления (нет/мало автоматизация)

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

для каждого выпуска мы должны дать один update.sql файл, который содержит все новые сценарии таблицы, измените операторы, новые/измененные пакеты, роли, и т.д. Этот файл используется для обновления базы данных от 1 версии до 2.

, Что когда-либо мы включаем в update.sql файл выше один всего этого, операторы должны перейти к отдельным соответствующим файлам. как изменяются, оператор должен перейти к таблице как новый столбец (сценарий таблицы должен быть modifed не, оператор Alter добавляется, после создают сценарий таблицы в файле), таким же образом новые таблицы, роли и т.д.

Поэтому каждый раз, когда, если пользователь хочет обновить, он будет использовать первый update.sql файл для обновления. Если он захочет создать из царапины затем, то он будет использовать build.sql, который, уже имея все вышеупомянутые операторы, она делает базой данных в синхронизации.

sriRamulu Sriramis4u@yahoo.com