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

Я использую SQL-Server 2008 с Visual Studio Database Edition.

С этой настройкой синхронизация вашей схемы очень проста. В принципе, есть инструмент "сравните схему", который позволяет мне синхронизировать схему двух баз данных и/или схему базы данных с папкой создания script с контролем источника.

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

статические данные, указанные в коде. типичный пример: мои пользователи могут изменять свои настройки, а их конфигурация хранится на сервере. Однако существует системное значение по умолчанию для каждого параметра, которое используется в случае, если пользователь не переопределил его. Таблица, содержащая эти настройки по умолчанию, увеличивается с добавлением дополнительных параметров в программу. Это означает, что когда включена новая функция/опция, общесистемный параметр по умолчанию обычно создается и в базе данных.
статические данные. например. список продуктов, в котором находится раскрывающийся список. Программа не полагается на существование определенного продукта в списке для работы. Это может быть, например, список продуктов, закодированных в кодировке Unicode, которые должны быть развернуты при создании новой версии Unicode программы.
другие данные, т.е. все остальное (журналы, учетные записи пользователей, пользовательские данные и т.д.)

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

Но что касается статических данных, мне интересно, что делать.

Должен ли я добавлять скрипты вставки к скриптам создания? или, возможно, использовать отдельные сценарии?
Как я (как разработчик) предупреждает людей, выполняющих развертывание, что они должны выполнить инструкцию insert?
Должен ли я дифференцировать данные двух типов? (первый из которых обычно создается разработчиком, а второй - не-dev)

Как вы управляете статическими данными БД?

Ответ 1

Я объяснил технику, которую использовал в своем блоге Контроль версий и Ваша база данных. Я использую метаданные базы данных (в этом случае расширенные свойства SQL Server) для хранения развернутой версии приложения. У меня есть только сценарии, которые обновляются от версии к версии. При запуске приложение считывает развернутую версию из метаданных базы данных (отсутствие метаданных интерпретируется как версия 0, т.е. Пока ничего не развернуто). Для каждой версии есть функция приложения, которая обновляется до следующей версии. Обычно эта функция запускает внутренний ресурс T-SQL script, который выполняет обновление, но это может быть что-то еще, например, развертывание сборки CLR в базе данных.

Нет script для развертывания "текущей" схемы базы данных. Новые партии итерации проходят через все промежуточные версии от версии 1 до текущей версии.

В этой технике есть несколько преимуществ:

Мне легко проверить новую версию. У меня есть резервная копия предыдущей версии, я применяю обновление script, затем могу вернуться к предыдущей версии, изменить script, повторить попытку, пока я не доволен результатом.
Мое приложение может быть развернуто поверх любой предыдущей версии. Различные клиенты имеют различную развернутую версию. Когда они обновляются, мое приложение поддерживает обновление с любой предыдущей версии.
Нет никакой разницы между новой установкой и обновлением, она запускает один и тот же код, поэтому у меня меньше кодовых путей для поддержки и тестирования.
Нет никакой разницы между изменениями DML и DDL (ваш исходный вопрос). все они обрабатывались одинаково, как script, чтобы перейти от одной версии к следующей. Когда мне нужно внести изменения, как вы описываете (измените значение по умолчанию), я действительно увеличиваю версию схемы, даже если не происходит никакого другого изменения DDL. Таким образом, в версии 5.1 по умолчанию было "foo", в 5.2 по умолчанию "bar", и это единственное различие между двумя версиями, а шаг "upgrade" - это просто оператор UPDATE (после чего, конечно, изменяется метаданные версии, то есть sp_updateextendedproperty).
Все изменения находятся в исходном управлении, в части источников приложения (главным образом, в сценариях T-SQL).
Я могу легко перейти к любой предыдущей версии схемы, например. чтобы воспроизвести жалобу клиента, просто выполнив последовательность обновления и остановившись на интересующей меня версии.

Этот подход спас мою кожу несколько раз, и теперь я верен. Существует только один недостаток: нет очевидного места для поиска в источнике, чтобы найти "какова текущая форма процедуры foo?". Поскольку последняя версия foo могла быть обновлена 2 или 3 версии назад, и с тех пор она не изменилась, мне нужно посмотреть обновление script для этой версии. Я обычно прибегаю к простому изучению базы данных и тому, что там, а не к поиску сценариев обновления.

Последнее замечание: на самом деле это не мое изобретение. Это моделируется именно после того, как сам SQL Server обновляет метаданные базы данных (mssqlsystemresource).

Ответ 2

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

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

Ответ 3

В Red Gate мы недавно добавили функцию сравнения данных SQL, позволяющую хранить статические данные как DML (один файл .sql для каждой таблицы) вместе с DDL схемы, который в настоящее время поддерживается SQL Compare.

Чтобы понять, как это работает, вот диаграмма, которая объясняет, как это работает.

Идея состоит в том, что, когда вы хотите нажать изменения на своем целевом сервере, вы выполняете сравнение, используя сценарии в качестве источника исходных данных, который генерирует необходимую DML-синхронизацию script для обновления цели. Это означает, что вам не нужно предполагать, что цель воссоздается с нуля каждый раз. Со временем мы надеемся поддерживать статические данные в нашем предстоящем инструменте управления SQL Source.

Дэвид Аткинсон, менеджер по продуктам, программное обеспечение Red Gate

Ответ 4

Мне очень нравится ваше различие в трех типах данных.

Я согласен для третьего.

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

Если есть дополнительная информация, которую мы хотели бы иметь в базе данных, например, если ее можно изменить на сайт клиента, мы разделим ее. Другие таблицы могут ссылаться на эти данные (либо по индексу ex: 0, 1, 2, 3, либо по коду ex: EMPTY, SIMPLE, DOUBLE, ALL).

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

Как я (как разработчик) предупреждать людей, выполняющих развертывание, что они должны выполнить инструкцию insert?

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

Ответ 5

Я столкнулся с этим при разработке систем CMS.

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

Ответ 6

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

Это имеет еще одно преимущество: если схема изменяется, во многих случаях вам не нужно восстанавливать все ваши инструкции INSERT - вы просто меняете инструмент.

Ответ 7

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

Изменить: * новый

все-в-одном или отдельном script?, это не имеет значения, если вы (команда разработчиков) согласны с вашей командой развертывания. Я предпочитаю разделять файлы, но я все равно всегда могу создать all-in-one.sql из тех, которые находятся в правильном порядке [Logins, Roles, Users; Tables; Views; Stored Procedures; UDFs; Static Data; (Audit Tables, Audit Triggers)]
как вы убедитесь, что они его выполнили: сделайте еще один шаг в документации по развертыванию приложений/баз данных. Если вы развертываете приложение, которое действительно нуждается в конкретных (новых) статических данных в базе данных, тогда вы можете выполнить проверку версии базы данных в своем приложении. и вы обновите DB_VERSION до вашего нового номера выпуска как часть этого script. Затем ваше приложение при запуске должно проверить его и сообщить об ошибке, если требуется новая версия базы данных.
dev и не-dev статические данные. Я никогда не видел этого случая. Чаще всего существуют реальные статические данные, которые вы можете назвать "dev", что является основной конфигурацией, статическими данными ISO и т.д. Другим типом является данные поиска по умолчанию, что там для пользователей, чтобы начать, но они могут добавить больше. Механизм INSERT этих данных может быть другим, потому что вам нужно убедиться, что вы не уничтожаете (power-) созданные пользователем данные.

Ответ 8

Во-первых, я никогда не использовал Visual Studio Database Edition. Вы благословлены (или прокляты) любыми инструментами, которые дает вам эта утилита. Надеюсь, это включает в себя большую гибкость.

Я не знаю, что я сделал бы большую разницу между статическими данными типа 1 и 2. Оба являются наборами данных, которые определены один раз, а затем никогда не обновляются, запрещая последующие выпуски и обновления, правильно? В этом случае основное различие заключается в том, как и почему данные такие, как есть, и не столько в том, как они хранятся, либо инициализируются. (Если данные не являются специфичными для среды, как в "A" для разработки, "B" для Production. Это будут "данные типа 4", и я буду бояться его игнорировать в этом сообщении, потому что я решил использовать SQLCMD переменные, и они дают мне головную боль.)

Во-первых, я создал бы script для создания всех таблиц в базе данных - предпочтительно только один script, иначе вы можете иметь много сценариев, лежащих вокруг (и find-and-replace при переименовании столбцов становится очень неудобно). Затем я сделаю script для заполнения статических данных в этих таблицах. Этот script может быть добавлен в конец таблицы script или сделать его собственным script, или даже сделал один script за таблицу, хорошая идея, если у вас есть сотни или тысячи строк для загрузки. (Некоторые люди создают файл csv, а затем выдают на него BULK INSERT, но я бы избегал этого, это просто дает вам два файла и сложный процесс [настройка сопоставлений дисков при развертывании] для управления.)

Главное, чтобы помнить, что данные (хранящиеся в базах данных) могут и будут меняться со временем. Редко (если когда-либо!) У вас будет роскошь удалять вашу базу данных Production и заменять ее свежей, блестящей, новой, лишенной всех этих грубых данных прошлых лет. Базы данных касаются изменений со временем и того, где скрипты приходят в свои собственные. Вы начинаете с скриптов для создания базы данных, а затем со временем вы добавляете скрипты, которые изменяют базу данных по мере внесения изменений, - и это относится также к вашим статическим данным (любого типа).

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

Ответ 9

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

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