it-swarm-ru.tech

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

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

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

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

Edit: Wow, спасибо за все отличные предложения, ребята! Я бы хотел выбрать более одного "Принятого ответа"!

68
Dana

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

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

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

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

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

Используя 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 без какого-либо специального программного обеспечения.

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

43
Robert Paulson

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

8
Manu

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

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

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

8
japollock

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

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

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

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

5
icelava

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

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

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

5
Rick

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

4
Adrian Mouat

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

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

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

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

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

3
Ed Lucas

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

3
anopres

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

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

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

[Корень]
[приложение]
[Версия]
[Сценарий]

\ скрипты
Мое заявление\
1.2.1 \
001.MyTable.Create.sql
002.MyOtherTable.Create.sql
100.dbo.usp.MyTable.GetAllNewStuff.sql

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

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

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

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

2
Dean Poulin

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

Для любого нового проекта есть установленная процедура. У нас есть сценарий создания схемы в версии 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 ...)

2
John Rudy

В моей компании мы, как правило, храним все элементы базы данных в системе контроля версий в виде отдельных сценариев, так же как и для отдельных файлов кода. Любые обновления сначала делаются в базе данных, а затем переносятся в репозиторий исходного кода, поэтому сохраняется история изменений.
На втором этапе все изменения базы данных переносятся в базу данных интеграции. Эта база данных интеграции представляет собой то, как должна выглядеть производственная база данных после развертывания. У нас также есть база данных QA, которая представляет текущее состояние производства (или последнее развертывание). После того, как все изменения внесены в базу данных Integration, мы используем инструмент сравнения схем (Red Gate SQL Diff для SQL Server), чтобы сгенерировать сценарий, который будет переносить все изменения из одной базы данных в другую.
Мы обнаружили, что это довольно эффективно, поскольку он генерирует единый скрипт, который мы можем легко интегрировать с нашими установщиками. Самая большая проблема, с которой мы часто сталкиваемся, это то, что разработчики забывают перенести свои изменения в интеграцию.

1
Mitch

Хранимые процедуры получают 1 файл на sp со стандартом, если существуют операторы drop/create сверху. Представления и функции также получают свои собственные файлы, чтобы их было проще создавать и использовать повторно.

Схема - это все 1 сценарий для начала, тогда мы сделаем изменения версии.

Все это хранится в проекте базы данных Visual Studio, подключенном к TFS (@ work или VisualSVN Server @ home для личных вещей) со структурой папок следующим образом:
- проект
- функции
- схема
-- хранимые процедуры
-- Просмотры

1
knight0323

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

0
Rikalous

Мы храним хранимые процедуры в системе контроля версий.

0
Darren Kopp

Мы храним все, что связано с приложением, в нашей SCM Сценарии БД обычно хранятся в их собственном проекте, но обрабатываются так же, как и любой другой код ... проектирование, реализация, тестирование, принятие.

0
Chris Hall

Все сценарии (создание объектов и т.д.) И сохраните эти сценарии в системе контроля версий. Как изменения туда попадают? Это часть стандартной практики того, как все делается. Нужно добавить таблицу? Напишите скрипт CREATE TABLE. Обновить sproc? Отредактируйте скрипт хранимой процедуры.

Я предпочитаю один скрипт на объект.

0
ahockley

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

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

0
John Flinchbaugh

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

Мне было бы интересно услышать, могут ли люди сделать это автоматически.

0
Rik