Хранимые процедуры / схема БД в системе контроля версий

Question

Ребята, вы отслеживаете хранимые процедуры и схему базы данных в выбранной вами системе контроля версий?

Когда вы вносите изменения (добавляете таблицу, обновляете сохраненный процесс, как вы вносите изменения в систему контроля версий?

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

Редактировать: Ого, спасибо за отличные предложения, ребята! Я хотел бы выбрать более одного «Принятого ответа»!

Answer 1

Мы выбираем все сценарии, включая все хранимые процедуры и изменения схемы. Никаких инструментов wysiwyg, и никакие необычные программы синхронизации не требуются.

Изменения схемы просты, все, что вам нужно сделать, это создать и поддерживать один файл для этой версии, включая все изменения схемы и данных. Это становится вашим скриптом преобразования из версии х в х + 1. Затем вы можете запустить его для производственной резервной копии и интегрировать ее в свою «ежедневную сборку», чтобы убедиться, что она работает без ошибок. Обратите внимание, что важно не изменять или удалять уже написанную схему / загрузку данных sql, так как вы можете в конечном итоге нарушить любой sql, написанный позже.

-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO

-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO

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

Используя Sql Server, синтаксис выглядит следующим образом:

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO

CREATE PROCEDURE [usp_MyProc]
(
    @UserID INT
)
AS

SET NOCOUNT ON

-- stored procedure logic.

SET NOCOUNT OFF

GO  

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

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

addendum: Рик прав, что вы потеряете разрешения для хранимых процедур с помощью DROP / CREATE, поэтому вам может потребоваться написать другой сценарий, чтобы повторно включить определенные разрешения. Этот сценарий разрешений будет запущен последним. Наш опыт обнаружил больше проблем с семантикой ALTER vers DROP / CREATE. YMMV

Answer 2

создайте «Проект базы данных» в Visual Studio для написания и управления вашим кодом sQL, а также сохраняйте проект под контролем версий вместе с остальным решением.

Answer 3

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

01.CreateUserTable.sql
02.PopulateUserTable
03.AlterUserTable.sql
04.CreateOrderTable.sql

Идея заключалась в том, что мы всегда знали, в каком порядке запускать сценарии, и мы могли избежать необходимости решать проблемы целостности данных, которые могут возникнуть, если вы попытаетесь изменить сценарий № 1 (который может привести к сбою вставок в № 2) .

Answer 4

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

Чтобы «навязать» это моим командам, наши решения поддерживают как минимум один проект базы данных из Visual Studio Team Edition для специалистов по базам данных . Как и в других проектах решения, проект базы данных получает контроль версий. Это делает естественным процесс разработки, разбивающий все в базе данных на обслуживаемые куски, «дисциплинируя» мою команду на этом пути.

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

• развертывание данных из файлов CSV .
• выборочное развертывание тестовых данных на основе типа сборки .
• Сбой Visual Studio при сравнении с базами данных с определенным типом сборки CLR, встроенной в .
• нет никаких различий между тестовыми / производственными базами данных, которые реализуют разные схемы аутентификации - пользователи SQL против пользователей Active Directory.

Но для команд, у которых нет практики создания версий своих объектов базы данных, это хорошее начало. Другой известной альтернативой, конечно же, является набор продуктов SQL Server от Red Gate , который большинство людей, использующих их, считают превосходящим предложение Microsoft.

Answer 5

При работе со сценариями удаления / создания в SQL Server следует помнить, что разрешения на уровне объектов будут потеряны. Мы изменили наш стандарт, чтобы использовать вместо него сценарии ALTER, которые поддерживают эти разрешения.

Есть несколько других предостережений, например, тот факт, что при отбрасывании объекта удаляются записи зависимостей, используемые sp_depends, а создание объекта только создает зависимости для этого объекта. Поэтому, если вы удалите / создадите представление, sp_depends больше не будет знать о каких-либо объектах, ссылающихся на это представление.

Мораль истории, используйте сценарии ALTER.

Answer 6

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

Answer 7

Пара разных точек зрения из моего опыта. В мире Oracle все управлялось «созданием» сценариев DDL. Как упоминал Ахокли, по одному сценарию для каждого объекта. Если объект необходимо изменить, его сценарий DDL изменяется. Существует один сценарий-обертка, который вызывает все объектные сценарии, чтобы вы могли развернуть текущую сборку БД в любой среде, которую захотите. Это для основного ядра создания.

Очевидно, что в действующем приложении всякий раз, когда вы запускаете новую сборку, требующую, скажем, нового столбца, вы не собираетесь отбрасывать таблицу и создавать ее новой. Вы собираетесь сделать скрипт ALTER и добавить столбец. Таким образом, каждый раз, когда должны произойти изменения такого рода, всегда есть две вещи: 1) написать изменяющий DDL и 2) обновить ядро, создав DDL, чтобы отразить это изменение. Оба переходят в управление исходным кодом, но один сценарий изменения является более кратковременным изменением времени, поскольку он будет использоваться только для применения дельты.

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

В мире Microsoft мы использовали аналогичную тактику, но мы использовали продукт Red Gate для управления скриптами и дельтами. Все еще положить сценарии в систему контроля версий. Еще один скрипт на объект (таблица, sproc, что угодно). В начале некоторые администраторы баз данных предпочитали использовать графический интерфейс SQL Server для управления объектами, а не использовать сценарии. Но это сделало очень сложным последовательное управление предприятием по мере его роста.

Если DDL находится в управлении исходным кодом, тривиально использовать любой инструмент сборки (обычно ant) ​​для написания сценария развертывания.

Answer 8

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

Answer 9

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

Для любого нового проекта есть установленная процедура. У нас есть сценарий создания схемы в версии 1, сохраненный сценарий создания процедуры и, возможно, сценарий создания начальной загрузки данных. Все процедуры хранятся в одном, по общему признанию, массивном файле. Если мы используем Enterprise Library, мы включаем копию сценария создания для регистрации; если это проект ASP.NET, использующий каркас приложений ASP.NET (аутентификация, персонализация и т. д.), мы также включаем этот скрипт. (Мы сгенерировали его из инструментов Microsoft, затем доработали, пока он не работал реплицируемым образом на разных сайтах. Не весело, а ценное время.)

Мы используем магию CTRL + F, чтобы найти понравившийся нам процесс. :) (Нам бы понравилось, если бы в SQL Management Studio была навигация по коду, как у VS. Вздох!)

Для последующих версий у нас обычно есть сценарии upgradeSchema, upgradeProc и / или updateDate. Для обновления схемы мы как можно больше изменяем таблицы, создавая новые по мере необходимости. Для обновлений proc, мы УДАЛЯЕМ и СОЗДАЕМ.

Одна морщина всплывает с таким подходом. Легко создать базу данных, и легко получить новую до скорости в текущей версии БД. Тем не менее, необходимо соблюдать осторожность при создании DAL (что мы в настоящее время - обычно - делаем с SubSonic), чтобы гарантировать, что изменения БД / схемы / процесса синхронизируются чисто с кодом, используемым для доступа к ним. Однако в наших путях сборки есть пакетный файл, который генерирует SubSonic DAL, поэтому наша SOP извлекает код DAL, повторно запускает этот пакетный файл, а затем проверяет все обратно в любое время при изменении схемы и / или процедур. (Это, конечно, запускает сборку исходного кода, обновляя общие зависимости до соответствующих библиотек DLL ...)

Answer 10

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

Мы сохраним сценарии в управлении исходным кодом следующим образом (структура папок ниже):

Я немного устал от существующих соглашений о присвоении имен таблицам и хранимым процедурам, поэтому мне не хватает моего примера ...

[корень]
[Применение]
[Версия]
[скрипт]

\ скрипты
MyApplication \
1.2.1 \
001.MyTable.Create.sql
002.MyOtherTable.Create.sql
100.dbo.usp.MyTable.GetAllNewStuff.sql

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

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

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

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