源代码管理中的存储过程/数据库模式

Question

您是否在源代码管理系统中选择存储过程和数据库模式？

当你做出改变（添加表，更新的存储过程，你怎么修改源代码控制？

我们使用SQL Server在工作中，我已经使用的darcs的版本开始，但我很好奇的一般策略以及任何方便的工具

编辑：！哇，感谢所有伟大的建议，家伙，我希望我能选择多个“接受的答案”

！

Answer 1

我们选择编写所有脚本，包括所有存储过程和模式更改。没有wysiwyg工具，也没有花哨的'同步'程序是必要的。

模式更改非常简单，您只需为该版本创建和维护一个文件，包括所有模式和数据更改。这将成为从版本x到x + 1的转换脚本。然后，您可以针对生产备份运行它，并将其集成到“每日生成”中，以验证它是否正常工作。请注意，不要更改或删除已经编写的模式/数据加载sql，因为最终可能会破坏以后写入的任何SQL。

-- change #1234 
ALTER TABLE asdf ADD COLUMN MyNewID INT 
GO 

-- change #5678 
ALTER TABLE asdf DROP COLUMN SomeOtherID 
GO 

对于存储过程，我们为每个存储过程选择一个文件，并使用drop/create表单。所有存储过程都是在部署时重新创建的。缺点是，如果更改是在源代码管理之外完成的，则更改将丢失。同时，对于任何代码都是如此，但是您的DBA'a需要注意这一点。这确实会阻止团队以外的人员使用存储过程，因为他们的更改在升级时会丢失。

使用SQL Server，语法如下：

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1) 
drop procedure [usp_MyProc] 
GO 

CREATE PROCEDURE [usp_MyProc] 
(
    @UserID INT 
) 
AS 

SET NOCOUNT ON 

-- stored procedure logic. 

SET NOCOUNT OFF 

GO 

唯一剩下要做的就是写整理所有个人文件，并创建与整套更新的新文件的实用程序（作为单个脚本）。首先添加模式更改，然后递归目录结构并包含所有存储过程文件。

作为对所有脚本编写脚本的好处，您在读取和写入SQL时会变得更好。您还可以使整个过程更加精细，但这是如何在没有任何特殊软件的情况下对所有sql进行源代码控制的基本格式。

附录：瑞克是正确的，你将失去使用DROP/CREATE存储过程的权限，所以你可能需要编写另一个脚本将重新启用特定的权限。此权限脚本将是最后一个运行。我们的经验发现更多与ALTER和DROP/CREATE语义相关的问题。 YMMV

Answer 2

我们在源代码管理中保留存储过程。

Answer 3

脚本一切（对象创建等）并将这些脚本存储在源代码管理中。这些更改如何实现？这是事情如何完成的标准做法的一部分。需要添加一个表？编写一个CREATE TABLE脚本。更新sproc？编辑存储过程脚本。

我更喜欢每个对象一个脚本。

Answer 4

在Visual Studio中创建“数据库项目”以编写和管理您的sQL代码，并将项目与版本控制一起与解决方案的其余部分一起保存。

Answer 5

对于procs，将包含脚本包装的proc写入纯文件，并应用这些文件中的更改。如果它应用正确，那么您可以检入该文件，并且您也可以从该文件中重现该文件。

对于模式更改，您可能需要签入脚本才能逐步进行所做的更改。编写脚本，应用它，然后将其签入。然后可以构建一个过程，以便自动应用每个模式脚本。

Answer 6

我想你应该写一个脚本，它会自动设置你的数据库，包括任何存储过程。这个脚本应该放在源代码控制中。

Answer 7

我们确实在源代码管理中保留存储过程。我们（或者至少我）做的方式是在我的项目中添加一个文件夹，为每个SP添加一个文件并手动复制并粘贴代码。所以当我更改SP时，我手动需要更改文件的源代码管理。

我很想听听人们是否可以自动做到这一点。

Answer 8

我们在上一个工作中所使用的解决方案是，以数字作为它们添加到源代码控制脚本：

01.CreateUserTable.sql
02.PopulateUserTable
03.AlterUserTable.sql
04。 CreateOrderTable.sql

这个想法是我们总是知道运行脚本的顺序，并且我们可以避免必须管理数据完整性问题，如果您尝试修改脚本＃1（这可能会导致INSERT在＃ 2失败）。

Answer 9

我强烈建议在源代码控制中维护模式和存储过程。

保持存储过程版本允许它们在确定存在问题时被回滚。

模式是一个不太明显的答案，取决于你的意思。维护在源代码控制中定义表的SQL，复制环境（prod/dev/user等）非常有用。

Answer 10

我在当前项目中一直使用另一种方法 - 我们没有在源代码控制下获得数据库，而是在我们获得每个版本时使用数据库比较工具来编写更改。
到目前为止它一直工作得很好。

Answer 11

我们在SCM中存储与应用程序相关的所有内容。数据库脚本通常存储在他们自己的项目中，但与其他代码一样被处理......设计，实施，测试和提交。

Answer 12

从我的经验来看有不同的观点。在Oracle世界中，所有事情都由“创建”DDL脚本来管理。正如ahockley提到的，每个对象都有一个脚本。如果该对象需要更改，则会修改其DDL脚本。有一个包装脚本调用所有对象脚本，以便您可以将当前的数据库构建部署到任何您想要的环境。这是主要的核心创造。

显然，在一个实时应用程序中，无论何时您推送一个需要新列的新构建，您都不会删除该表并将其新建。你要做一个ALTER脚本并添加列。所以每当这种变化需要发生的时候，总会有两件事要做：1）编写alter DDL并且2）更新核心创建DDL以反映变化。两者都进入源代码控制，但单个更改脚本更多的是瞬间点更改，因为它只会用于应用增量。

你也可以使用像ERWin这样的工具来更新模型并向前生成DDL，但是我知道大多数DBA不相信建模工具会按照他们想要的方式创建脚本。您也可以使用ERWin将您的核心DDL脚本周期性地逆向工程模型化，但是让它看上去很正确（每次使用它的时候都是这样）。

在微软的世界里，我们采用了类似的策略，但我们使用Red Gate产品来帮助管理脚本和增量。仍然把脚本放在源代码控制中。每个对象仍然有一个脚本（表，sproc，不管）。在开始时，一些DBA确实倾向于使用SQL Server GUI来管理对象，而不是使用脚本。但是，随着企业的发展，这使得企业难以一致地管理。

如果DDL在源代码控制中，使用任何构建工具（通常是ant）来编写部署脚本是微不足道的。

Answer 13

在过去的经验中，我一直保持数据库更改源的方式，使得对于产品的每个版本，任何数据库更改总是以脚本形式存储在我们正在开发的版本中。现有的构建过程会根据数据库中的每个“应用程序”存储当前版本的表，自动使数据库达到当前版本。然后，我们编写的自定义.net实用程序应用程序将运行并确定数据库的当前版本，并按照脚本的前缀数量顺序对其运行任何新脚本。然后我们会运行单元测试来确保一切都很好。

我们会存储在源代码控制脚本如下（以下文件夹结构）：

我上表当前的命名约定和存储过程和我的例子所以裸有点生疏...

[根]
        [应用]
                [版]
                        [脚本]

\脚本
        MyApplication的\
                1.2.1 \
                        001.MyTable.Create。SQL
                        002.MyOtherTable.Create.sql
                        100.dbo.usp.MyTable.GetAllNewStuff.sql

使用一个版本表将考虑应用程序和版本，应用程序将恢复每周生产备份，并运行自当前版本以来针对数据库所需的所有脚本。通过使用.net，我们很容易将其打包成一个事务，如果有任何失败，我们会回滚，并发送电子邮件，所以我们知道该版本有坏脚本。

因此，所有开发人员都会确保在源代码管理中保持这一点，因此协调发布将确保我们计划针对数据库运行的所有脚本都能成功运行。

这可能比您寻找的信息更多，但它对我们非常有用，并且考虑到结构，很容易让所有开发人员参与其中。

当发布日期到来时，操作团队将按照发布说明从源代码控制中选取脚本，并使用我们在夜间构建过程中使用的.net应用程序对数据库运行包，这将自动打包脚本在事务中，所以如果失败了，它会自动回滚并且不会对数据库产生影响。

Answer 14

与上面的Robert Paulson类似，我们的组织将数据库置于源代码控制之下。然而，我们的区别是我们试图限制我们拥有的脚本数量。

对于任何新项目，都有一套程序。我们在版本1有一个模式创建脚本，一个存储的proc创建脚本和一个可能的初始数据加载创建脚本。所有特效都保存在一个单一的，无可否认的庞大文件中。如果我们使用企业库，我们会包含用于日志记录的创建脚本的副本;如果它是使用ASP.NET应用程序框架（认证，个性化等）的ASP.NET项目，那么我们也包含该脚本。 （我们使用微软的工具生成了它，然后对它进行了调整，直到它在不同的网站上以可复制的方式工作，没有趣味，但是宝贵的时间投资。）

我们使用魔法CTRL + F来查找我们喜欢的过程。 :)（如果SQL Management Studio有像VS那样的代码导航，我们很乐意）叹息！

对于后续版本，我们通常有upgradeSchema，upgradeProc和/或updateDate脚本。对于模式更新，我们尽可能地更改表，根据需要创建新表。对于proc更新，我们DROP和CREATE。

这种方法会弹出一个皱纹。生成一个数据库很容易，并且很容易获得新的数据库以加快当前的数据库版本。但是，必须小心DAL代（我们目前通常使用SubSonic），以确保DB/schema/proc更改与用于访问它们的代码完全同步。然而，在我们的构建路径中是一个生成SubSonic DAL的批处理文件，因此，我们的SOP是检出DAL代码，重新运行该批处理文件，然后在架构和/或特效更改的任何时候检查它。 （当然，这会触发源代码构建，将共享依赖项更新为适当的DLL ...）

Answer 15

我运行一个作业将其编写成正式的目录结构。

以下是从批处理文件调用的VS2005代码，命令行项目。代码末尾的app.config键。

它基于我在网上找到的其他代码。设置起来有点痛苦，但一旦你开始工作，效果会很好。

​​

Answer 16

有一件事要记住，在SQL Server中删除/创建脚本时，对象级权限将会丢失。我们改变了标准，改为使用ALTER脚本，它维护这些权限。

还有一些其他的注意事项，例如丢弃对象会丢弃sp_depends使用的依赖项记录，创建对象只会创建该对象的依赖项。因此，如果您删除/创建视图，则sp_depends将不再知道引用该视图的任何对象。

道德故事，使用ALTER脚本。

Answer 17

如果在顶部存在drop/create语句，存储过程将获得每sp一个文件与标准。视图和函数也可以获得他们自己的文件，以便更容易地进行版本和重用。

模式是所有1脚本开始，然后我们会做版本更改。

所有这一切都被存储在一个文件夹结构连接到TFS（@工作或VisualSVN服务器@家个人的东西）一个Visual Studio数据库项目如下：
- 项目
- 功能
- 架构
- 存储过程
- 观点

Answer 18

在我的公司，我们倾向于在源头控制作为单独的脚本中的所有数据库项存储库就像您个人代码文件。任何更新首先在数据库中进行，然后迁移到源代码存储库中，以保持更改的历史记录。
第二步，将所有数据库更改迁移到集成数据库。这个集成数据库正好代表了生产数据库应该看起来像部署后的样子。我们还有一个QA数据库，代表当前的生产状态（或最后一次部署）。一旦在集成数据库中进行了所有更改，我们就会使用架构差异工具（Red Gate的SQL Diff for SQL Server）来生成一个将所有更改从一个数据库迁移到另一个数据库的脚本。
我们发现这是相当有效的，因为它生成一个脚本，我们可以轻松地与我们的安装程序集成。我们经常遇到的最大问题是开发人员忘记将他们的更改迁移到集成。

Answer 19

我同意（和upvote）罗伯特保尔森的做法。假设你正在控制一个有责任和纪律的开发团队来坚持这种做法。

“逼”那到我的团队，我们的解决方案保持从Visual Studio Team Edition for Database Professionals至少一个数据库项目。与解决方案中的其他项目一样，数据库项目也获得版本控制。这使得它成为一个自然的开发过程，可以将数据库中的所有内容都分解为可维护的块，从而“一路处理”我的团队。

当然，作为一个Visual Studio项目，它没有接近完美的地方。你会遇到很多怪癖，可能会让你感到沮丧或困惑。在完成任务之前，需要对项目的工作方式有一定的了解。示例包括：

• deploying data from CSV files。
• selective deployment of test data based on build type。
• Visual Studio crashing on comparing with databases with certain type of CLR assembly embedded within。
• 实现不同身份验证方案的测试/生产数据库之间没有区别 - SQL用户与Active Directory用户。

但是对于没有对数据库对象进行版本控制的团队来说，这是一个好的开始。另一个着名的替代方案当然是Red Gate's suite of SQL Server products，大多数使用它们的人都认为优于微软的产品。

Answer 20

我发现到目前为止，最简单，最快和最安全的方法就是咬住子弹并使用RedGate的SQL Source Control。只需几分钟即可编写并存储在存储库中。我只是希望RedGate将这款产品视为亏损领导者，以便它能够得到更广泛的应用。

Answer 21

如果您正在寻找简单的现成解决方案，我们的Sql Historian系统使用后台进程自动将DDL更改同步到TFS或SVN，对于任何对数据库进行更改的人都是透明的。根据我的经验，最大的问题在于维护源代码管理中的代码，并修改服务器上的内容 - 这是因为通常您必须依赖人员（甚至是开发人员）更改其工作流程并记住检查其更改在他们已经在服务器上完成之后。把这种负担放在一台机器上会让每个人的生活变得更轻松。