Необходимо ли сохранить Хранимые процедуры SQL в Управлении исходным кодом?
Ваши варианты использования охватываются встроенным правилом requre-jsdoc .
Eslint поставляется с поддержкой es6 +, если вы установите ecmaVersion: 6 в конфигурации.
module.exports = {
parserOptions: {
ecmaVersion: 6,
},
rules: {
"require-jsdoc": [
2,
{
require: {
FunctionDeclaration: true,
MethodDefinition: true,
ClassDeclaration: true,
ArrowFunctionExpression: true,
FunctionExpression: true
}
}
]
}
};
17 ответов
Да. Весь код должен быть сохранен в управлении исходным кодом.
Проще говоря, код является кодом, и ошибки происходят. Хорошо смочь возвратиться и видеть то, что изменялось со временем и смочь вернуться к тем изменениям.
Мы должны добавить его вручную к системе управления исходным кодом, но можно создать дополнения для SQL-сервера Система управления. Я никогда не создавал тот для автоматического добавления его к управлению исходным кодом, но я предполагаю, что Вы могли. Кроме того, весь код хранится в sql таблицах, таким образом, Вы могли в теории создавать процесс или что-то, чтобы пройти таблицу (таблицы) и получить весь код и фиксировать его автоматически.
Обновление: Я всегда писал бы дополнительный код, чтобы проверить и видеть, существует ли код и если он не создает процедуру заполнителя, и затем фактический сценарий делает и изменяет процедуру.
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
Выполнение отбрасывания и воссоздает, удалит все полномочия пользователя, у Вас есть установка для него.
Если Вы не используете управление активами вместе с управлением исходным кодом, то, как я говорю, бросают все в управление исходным кодом. Изображения, документы слова, целая хижина. Не может потерять его, может всегда обращать любые изменения к нему и если какая-либо машина понижается - ничто не потеряно.
Существуют методы в SMO для генерации сценариев, если Вы предпочитаете кодировать свой собственный инструмент сценариев.
http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated
Как другие сказали, да они должны быть.
Я не знаю о простом способе сделать это с Studio управления SQL Server, но если Вы также используете Visual Studio, проекты базы данных являются отличным способом управлять этим.
SQL procs также, конечно, нужна та же безопасность/преимущества управления версиями как остальная часть кода в проекте.
SPS и схемы таблицы в этом отношении являются всеми активами, которые должны являться объектом управления версиями. В идеальном мире DB был бы создан из сценариев, включая данные тестирования, как часть Вашего процесса CI. Даже если это не имеет место, имение DB/разработчика является хорошей моделью для следования. Таким образом новые идеи могут быть испытаны в локальной тестовой среде, не влияя на всех, после того как изменение тестируется, в нем можно зарегистрироваться.
Studio управления может быть связан с управлением исходным кодом, хотя у меня нет опыта выполнения этого. Мы всегда отслеживали наш SP/схему как файлы. Студия управления может автоматически генерировать сценарии изменения, которые очень полезны, поскольку таблица, drop/recreate, может быть слишком жестокой для любой таблицы, которая имеет данные.
Вы должны.
К моему знанию никакой такой инструмент не существует для автоматизации этого процесса. По крайней мере, пять лет назад, когда я рассматривал создание того, казалось, не было никакой конкуренцией.
Мы храним наш procs в Подверсии, весь Ваш код SQL включая DDL должен быть в некотором репозитории управления исходным кодом
SQL является кодом. Весь код относится к управлению исходным кодом.
Это - все.
Совершенно определенно да. Затем вопрос становится, как Вы храните их в управлении исходным кодом. Вы отбрасываете и воссоздаете хранимую процедуру или просто изменяетесь, Вы добавляете полномочия в конце сценария или в отдельном сценарии. Было сообщение при Кодировании Ужаса некоторое время назад о теме, которую я нашел интересным. Ваша База данных При Управлении версиями?
Уверенный Вы должны.
В MS SQL 2008, можно сделать его правильно от Studio управления.
Хранение хранимых процедур является прекрасной идеей. Это - боль все же. Как Вы получаете все это в подверсию? Можно вручную сделать это, но затем его утомительное и Вы заканчиваете тем, что не делали его вообще.
Я использую инструмент из дозвукового проекта.
sonic.exe version /server servername /db databasename /out outputdirectory
Эта команда сохраняет все к 2 текстовым файлам. Каждый содержит схему базы данных, сохранил procs, учетные записи пользователей, ограничения и первичные ключи. Другой содержит данные.
Теперь, когда у Вас есть эти два файла, можно использовать подверсию (cvs, безопасный источник) для перемещения его в управление исходным кодом.
Больше информации для использования Инструмента Командной строки (Подкомандующий)
Я рекомендую действительно сохранить их. Вы никогда не знаете, когда необходимо будет откатывать, или рыть в логику, Вы, возможно, удалили..
Вот хороший способ легко захватить Ваш Сохраненный Procs в файлы, которые можно бросить в любое управление исходным кодом, которого Вы требуете..
Получите свою базу данных при управлении версиями. Проверьте ряд сообщений Scott Allen.
Когда дело доходит до управления версиями база данных часто является вторым или даже гражданином третьего класса. Из того, что я видел, команды, которые никогда не думали бы о написании кода без управления версиями через миллион лет - и справедливо так - могут так или иначе абсолютно не обращать внимания на потребность в управлении версиями вокруг критических баз данных, на которые полагаются их приложения. Я не знаю, как можно назвать себя разработчиком программного обеспечения и поддержать невозмутимый вид, когда база данных не находится под точно тем же строгим уровнем управления исходным кодом как остальная часть кода. Не позволяйте этому произойти с Вами. Получите свою базу данных при управлении версиями.
АБСОЛЮТНО ПОЛОЖИТЕЛЬНО НЕСОМНЕННО НИКАКИЕ ИСКЛЮЧЕНИЯ ВО ВСЕЙ БЕСКОНЕЧНОСТИ ВСЮДУ ПО ВСЕЛЕННОЙ ДА!
Абсолютно. Положительно.
Ряд SPS является интерфейсом, который, вероятно, будет изменяться более часто, чем структурные изменения. И потому что SPS содержит бизнес-логику, изменения должны быть сохранены в управлении версиями для отслеживания модификаций и корректировок логики.
Хранение их в управлении версиями является признаком организационной зрелости на уровне кодирования и является лучшей практикой.