Следует ли хранить хранимые процедуры SQL в контроле источника?

При разработке приложения с большим количеством хранимых процедур следует хранить их в какой-то исходной системе управления версиями (например, с помощью источника, TFS, SVN)? Если да, то почему? И есть ли удобный интерфейс для этого с SQL Server Management Studio?

ОТВЕТЫ

Ответ 1

Да. Весь код должен храниться в исходном элементе управления.

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

Мы должны добавить его вручную в систему управления версиями, но вы можете создавать аддоны для Sql Server Management System. Я никогда не создавал его, чтобы автоматически добавлять его в исходный элемент управления, но, полагаю, вы могли бы. Кроме того, весь код хранится в таблицах sql, поэтому вы могли бы теоретически создать процесс или что-то, что бы пройти через таблицу (таблицы) и получить весь код и зафиксировать его автоматически.

Обновление: я всегда буду писать дополнительный код для проверки и посмотреть, существует ли код, и если он не создает процедуру заполнения, а затем действительную процедуру script do and alter.

IF NOT EXISTS (SELECT * FROM dbo.sysobjects WHERE 
id = OBJECT_ID(N'[dbo].[SomeStoredProcedure]') AND 
OBJECTPROPERTY(id,N'IsProcedure') = 1)

EXEC sp_executesql N'CREATE PROCEDURE [dbo].[SomeStoredProcedure] AS

SELECT ''SPROC Template'''

GO

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

 ALTER PROCEDURE SomeStoredProcedure

Выполнение сброса и повторного создания удалит все пользовательские разрешения, которые вы установили для него.

Ответ 2

АБСОЛЮТНО ПОЗИТИВНО БЕЗ ВОПРОСОВ НИКАКИХ ИСКЛЮЧЕНИЙ В ВСЕМ ВОЗМОЖНОСТЕ ЧЕРЕЗ ВСЕЛЕННОЕ ДА!

Ответ 3

Получите вашу базу данных под контролем версий. Проверьте серию сообщений Скотта Аллена.

Когда дело доходит до контроля версий, база данных часто является гражданином второго или даже третьего сорта. Из того, что я видел, команды, которые никогда бы не подумали о написании кода без контроля версий за миллион years-- и справедливо so--, могут каким-то образом полностью забывать о необходимости контроля версий критически важных баз данных, на которые полагаются их приложения. Я не знаю, как вы можете называть себя инженером-программистом и вести себя открыто, когда ваша база данных находится не на том же строгом уровне контроля исходного кода, что и остальная часть вашего кода. Не позволяй этому случиться с тобой. Получите вашу базу данных под контролем версий.

Ответ 4

Определенно да. Тогда возникает вопрос, как вы храните их в системе контроля версий. Вы удаляете и воссоздаете хранимую процедуру или просто изменяете, добавляете ли вы разрешения в конце скрипта или в отдельный скрипт. Некоторое время назад была статья о Coding Horror, которая показалась мне интересной. Ваша база данных находится под контролем версий?

Ответ 5

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

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

Сохраненные процедуры для файлов .sql

Ответ 6

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

Я использую инструмент из вспомогательного проекта .

sonic.exe version /server servername /db databasename /out outputdirectory

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

Теперь, когда у вас есть эти два файла, вы можете использовать subversion (cvs, source safe), чтобы переместить его в исходный элемент управления.

Дополнительная информация для с помощью инструмента командной строки (SubCommander)

Ответ 8

SQL - это код. Весь код принадлежит управлению исходным кодом.

Вот и все.

Ответ 9

Совершенно верно. Положительно.

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

Хранение данных в управлении версиями является симптомом организационной зрелости на уровне кодирования и является наилучшей практикой.

Ответ 10

Наиболее определенно.

Ответ 11

Вы должны.

Насколько мне известно, такой инструмент не существует для автоматизации этого процесса. По крайней мере, пять лет назад, когда я думал о строительстве одного, конкуренция не представляла.

Ответ 12

Мы сохраняем наши procs в Subversion, весь ваш код SQL, включая DDL, должен быть в каком-то репозитории управления версиями

Ответ 13

SP и схемы таблиц - это все активы, которые должны находиться под контролем версий. В идеальном мире БД будет построена из сценариев, включая тестовые данные, как часть вашего процесса CI. Даже если это не так, наличие DB/разработчика - хорошая модель для подражания. Таким образом, новые идеи могут быть опробованы в локальной песочнице, не затрагивая всех, как только тестирование будет проверено, он может быть проверен.

Management Studio может быть связана с контролем источника, хотя у меня нет опыта в этом. Мы всегда отслеживали нашу SP/схему как файлы. Студия управления может автоматически генерировать сценарии изменений, которые очень полезны, так как таблица drop/rereate может быть слишком тяжелой для любой таблицы с данными.

Ответ 14

SQL-proc также обязательно нуждается в той же безопасности/преимуществах управления версиями, что и остальная часть кода в проекте.

Ответ 15

Как говорили другие, да, они должны быть.

Я не знаю простого способа сделать это с помощью SQL Server Management Studio, но если вы также используете Visual Studio, проекты с базами данных - отличный способ справиться с этим.

Ответ 17

Если вы не используете управление активами наряду с контролем источника, тогда я говорю "бросить все в исходном контроле". Изображения, текстовые документы, весь шебанг. Не могу потерять его, всегда можно отменить любые изменения, и если какая-либо машина опустится - ничего не потеряно.