Проверка сохраненного процесса в системе контроля версий: что нужно проверить?

Question

У меня есть несколько SP, которые я хочу контролировать под контролем, но вопрос в том, что мне добавить?

В идеале я хочу каким-то образом получить исходный текст SP, однако все, что я могу получить, - это сценарии изменения, создания и т. Д., Которые я не считаю необработанным источником. Самое близкое, что я могу получить, это запустить sp_helptext 'mysp'.

Есть ли какой-нибудь способ получить источник SP?

Я использую SQL Server 2008 R2.

РЕДАКТИРОВАТЬ: я понимаю полезность возможности получить то, что находится в контроле исходного кода и обновления / развертывания SP, однако я решительно против этого. Этот код полезен ситуативно, не имеет значения при создании различий для просмотра изменений и общего характера (нарушает принцип DRY. Например, в SQL Server 2010 появился новый способ создания и удаления sps. Нужно обновить «источник» для всех моих SP?). Если бы я хотел что-то подобное, я был бы гораздо более склонен создать скрипт, который будет развертывать SP на сервере (например, deploy dp_mysp prod).

Есть ли способ получить только интуицию SP? Или он на самом деле хранится как скрипт процедуры создания?

РЕДАКТИРОВАТЬ2:

Приветствия, ребята.

Я не возражаю против настроек и ссылок управления версиями (или сценариев развертывания, которые являются лучшей аналогией IMO), поскольку они существуют в одном месте и являются многократно используемыми кусочками совершенства. Ключевым моментом здесь является то, что тот же код развертывания существует во многих местах и ​​должен поддерживаться во многих местах. Нет никакой зависимости между этим кодом и каждым sp, поэтому он добавляет Cruft к каждому sp. Почему бы нам не добавить общий код развертывания к каждому файлу в нашем решении, чтобы он мог быть развернут самостоятельно?

В любом случае, я думаю, нам придется согласиться с этим не согласиться. Я определенно являюсь пуристом, и я не думаю, что есть много практической выгоды от того, что я хочу, но для меня то, что я супер анал в разработке - это то, что делает это забавным:)

Никто не помог мне приблизиться к тому, что я хочу, чем sp_helptext 'mysp' (и я предполагаю, что это невозможно в данный момент) или убедил меня, что я должен проверить что-то еще, поэтому я собираюсь оставить вопрос без ответа.

Еще раз спасибо.

Answer 1

До VS 2010 я использовал сценарий для создания процедуры-заглушки, если она еще не существует, а затем "изменил процедуру" с помощью действующего кода:

if not exists (select * from sys.objects where name = 'myProc' and type = 'P')
begin
    exec('create procedure myProc as print ''stub''')
end
GO
alter procedure myProc as 
....

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

Answer 2

Создайте проект базы данных только в VS2010 (окончательный вариант), сравните схему с локальной базой данных и сохраните репозиторий в TFS. Это позволит сохранить все изменения SP в TFS

.

Answer 3

У вас есть доступ к Visual Studio 2010?Они объединили DB Pro с версией Developer, предоставляя вам доступ к проектам баз данных и сравнению схем.Используя эти инструменты, вы можете легко извлекать все таблицы, представления, хранимые процедуры, пользовательские функции и т. Д. В формате на основе файлов.Затем вы можете сохранить этот проект базы данных в системе контроля версий.Вы даже можете сравнить различные ревизии проекта, чтобы увидеть, что изменилось, не говоря уже о развертывании на серверах.

Если у вас нет этого инструмента, вам нужно будет написать сценарий процедуры.На моей предыдущей работе нам было хорошо с инструкциями create.

Answer 4

по моему мнению, то, что вы хотели бы поставить под контроль исходного кода, было бы сценарием, содержащим if exists(...) drop с последующим create procedure и необходимыми разрешениями.таким образом, вы можете вернуться к тому же самому пути, который был во время входа в систему контроля версий.

помните, что сами операторы sql - это не единственное, что вы должны отслеживать.

Answer 5

Возможно, вам придется подождать SQL 2011 (Denali)

Майкл Оти говорит:

"Джуно также может проанализировать набор изменений и сгенерировать сценарий, который обновит базу данных и всеобъекты, затронутые изменениями, которые вы вносите в среду разработки. Как и Visual Studio, Джуно поддерживает концепцию проектов и может быть интегрирован с системой контроля версий с помощью Team Foundation Server. Одной из более интересных функций является возможность Джуно сразу переходить к определениям столбцов илипоказать все ссылки на данный столбец. Одна из целей Джуно - сделать среду разработки согласованной как для SQL Azure, так и для локальной версии SQL Server. "

http://www.sqlmag.com/article/sql-server/first-look-sql-server-code-named-denali

«Джуно», оболочка VS2010 для SQL Server:

http://blogs.msdn.com/b/ssdt/archive/2010/11/08/welcome.aspx

Answer 6

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

SELECT ROUTINE_DEFINITION 
FROM INFORMATION_SCHEMA.ROUTINES 
WHERE ROUTINE_NAME = '<sp_name>'

Вы можете запросить это в файлах на любом языке программирования, который вы предпочитаете. Вы заметите, что само ядро ​​базы данных хранит CREATE PROCEDURE...

Одна из причин, по которой я думаю, что этот подход трудно поддерживать, состоит в том, что стоит запомнить некоторые настройки сеанса на уровне сеанса, в котором создается хранимая процедура, влияет на то, как / будет ли функционировать sp - например, эффект настройки QUOTED_IDENTIFIER для хранимых процедур с использованием функций XML - вам потребуется какой-то способ записи / получения этих настроек для каждой процедуры.

Answer 7

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

• Предложение "выполнить как"
• Параметры для хранимой процедуры (и их значения по умолчанию)
• Предложение о перекомпиляции

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

Answer 8

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

Я включаю три раздела в каждый хранимый сценарий proc:

1. Небольшая проверка в верхней части скрипта, чтобы удалить сохраненный процесс, если он существует (заканчивается GO)

2. Создание сохраненного процесса (заканчивается GO)

3. Затем список любых грантов для сохраненного процесса. (Подразумевается GO)

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