您应该将SQL存储过程存储在源代码管理中吗？

Question

在开发具有大量存储过程的应用程序时，是否应将它们存储在某种源版本控制系统中（例如源安全，TFS，SVN）？ 如果是这样，为什么？ 使用SQL Server Management Studio是否有方便的前端方式？

Answer 1

是。 所有代码都应存储在源代码管理中。

简单地说，代码是代码，错误发生。 很高兴能够回头看看随着时间的推移发生了什么变化，并能够回到这些变化。

我们必须手动将其添加到源控制系统，但您可以为Sql Server管理系统创建插件。 我没有创建一个自动添加到源代码控制，但我想你可以。 此外，所有代码都存储在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

执行删除并重新创建将删除您为其设置的所有用户权限。

Answer 2

绝对没有问题，没有任何问题在整个宇宙中都没有异常！

Answer 3

在版本控制下获取数据库 。 查看Scott Allen的一系列帖子。

在版本控制方面，数据库通常是第二类甚至是三等公民。 从我所看到的情况来看，那些在没有版本控制的情况下永远不会想到编写代码的团队在一百万年之内 - 这是正确的 - 在某种程度上可以完全忘记对应用程序所依赖的关键数据库进行版本控制的需求。 我不知道当你的数据库与其他代码完全没有完全相同的源代码控制级别时，你怎么称自己为软件工程师并保持直面。 不要让这件事发生在你身上。 在版本控制下获取数据库。

Answer 4

绝对是肯定的。 然后问题就变成了如何将它们存储在源代码管理中。 您是删除并重新创建存储过程还是只是更改，是在脚本末尾还是在单独的脚本中添加权限。 关于我发现有趣的主题，有一篇关于Coding Horror的帖子。 您的数据库是否受版本控制？

Answer 5

我建议你存储它们。 你永远不知道什么时候你需要回滚，或者挖掘你可能已经删除的逻辑。

这是一个很好的方法，可以轻松地将您的存储过程抓取到文件中，您可以将其放入您想要的任何源控件中。

存储过程到.sql文件

Answer 6

存储存储过程是个好主意。 虽然很痛苦。 你怎么把所有这些东西都变成了颠覆？ 你可以手动完成它，但是它很乏味，你最终完全没有这样做。

我使用亚音速项目的工具。

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

此命令将所有内容保存为2个文本文件。 一个包含数据库模式，存储过程，用户帐户，约束和主键。 另一个包含数据。

现在你有了这两个文件，你可以使用subversion（cvs，source safe）将它移动到源代码控制中。

有关使用命令行工具（SubCommander）的更多信息

Answer 7

当然你应该。

在MS SQL 2008 ，您可以直接从Management Studio执行此操作 。

Answer 8

SQL是代码。 所有代码都属于源代码控制。

就这些。

Answer 9

绝对。 积极。

一组SP是一个接口，可能比结构更改更频繁地修改。 并且由于SP包含业务逻辑，因此应将更改存储在版本控制中以跟踪对逻辑的修改和调整。

将这些存储在版本控制中是编码级别组织成熟度的一种表现，并且是最佳实践。

Answer 10

明确地。

Answer 11

你应该。

据我所知，没有这样的工具来自动化这个过程。 至少，五年前，当我考虑建造一个时，似乎没有任何竞争。

Answer 12

我们将我们的proc存储在Subversion中，包括DDL在内的所有SQL代码都应该存在于某种源代码控制库中

Answer 13

这个问题的SP和表模式都是应该受版本控制的资产。 在完美的世界中，数据库将根据脚本（包括测试数据）构建，作为CI过程的一部分。 即使情况并非如此，拥有数据库/开发人员也是一个很好的模型。 通过这种方式，可以在本地沙箱中尝试新的想法而不会影响每个人，一旦测试了更改，就可以检入。

Management Studio可以链接到源代码管理，但我没有这样做的经验。 我们一直将我们的SP /架构跟踪为文件。 管理工作室可以自动生成更改脚本，这非常有用，因为对于任何有数据的表，表删除/重新创建都可能过于繁重。

Answer 14

SQL procs肯定需要与项目中其余代码相同的版本控制安全性/好处。

Answer 15

正如其他人所说，是的，他们应该。

我不知道使用SQL Server Management Studio执行此操作的简单方法，但如果您还使用Visual Studio，则数据库项目是管理此方法的好方法。

Answer 16

如果您希望编写自己的脚本编写工具，SMO中有一些方法可以生成脚本。

http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated

Answer 17

如果你没有使用资源管理和源代码控制，那么我说把所有内容都放在源代码管理中。 图像，文字文件，整个shebang。 不能丢失它，可以随时撤消对它的任何更改，如果任何机器发生故障 - 什么都不会丢失。