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

Get your database under version control。查看Scott Allen的一系列帖子。

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

Answer 4

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

我使用subsonic project中的工具。

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

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

既然您拥有这两个文件，您可以使用subversion（cvs，source safe）将其移动到源代码管理中。

using The Command Line Tool (SubCommander)

的更多信息

Answer 5

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

Answer 6

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

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

Stored Procedures to .sql files

Answer 7

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

就是这样。

Answer 8

当然可以。

在MS SQL 2008中，您可以right from Management Studio。

Answer 9

绝对是最好的。

Answer 10

绝对。正。

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

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

Answer 11

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

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

Answer 12

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

Answer 13

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

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

Answer 14

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

Answer 15

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

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

Answer 16

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

Answer 17

你应该。

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

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

17 个答案: