当我们第一次启动源代码控制时，开发人员只需编辑数据库中的脚本，并在发布之前编写一个包含所有更改的大脚本。这很有效，直到其中一位开发人员意外删除了存储过程，所有工作都丢失了。SQL Server源代码控制
之后，我们把所有的脚本来创建文本文件中的存储过程和他们的源代码控制。这里的问题是，开发人员有时更新源代码管理或数据库中的存储过程，并忘记更新另一个。
我的梦想就是一个开发中去，并检查出一个存储过程有一个系统。然后，更改后，数据库会自动更新。
这只是一个梦吗？源代码管理SQL Server的最佳方式是什么？
我们一直在使用Visual Studio Team System Database Edition最近，我不得不说，它一直非常好。所有的存储过程都存储为文件，进出源控制的检查，它有工具来生成脚本等存储为文本文件
而且，在过去，我们已经使用脚本，在检查和脱离源代码管理。规则是你必须检出文件，然后编辑它，例如Management Studio，然后保存并重新检入。在每个存储过程脚本文件的顶部，它将删除现有的存储过程，然后使用CREATE语句创建一个新的（解决CREATE/ALTER问题）。然后，我们有了一个工具，可以按照正确的顺序运行所有脚本，从头构建一个空白数据库，然后我们使用RedGate的SQL Compare产品生成一个脚本，以使我们现有的数据库保持最新状态。我承认这很乏味。大约在同一时间，我与其他约10名开发人员一起工作，他们实施了严格的数据库变更管理程序。有许多应用程序都依赖于一组2或3个数据库。每当数据库模式必须改变时（我们只是在这里讨论表格，列和视图），然后创建一个文档来解释变化，然后有一个矩阵列出了变化与我们认为会影响的应用程序。然后，文件被分发，并且必须由每个应用程序的负责人进行审查，并且他们必须在任何可能受到影响的地方搜索他们的应用程序等等。这是一个漫长而艰难的过程，但它工作。但是，存储过程只是作为源代码管理中的文本文件存储。
在更久远的过去，与更像一个数据库作为数据存储，每一个应用程序启动时的桌面应用程序规模较小的项目，我想：
每当我需要更改架构，我只是在启动代码的末尾添加更多代码以根据需要修改架构，并注意迁移任何现有数据。这样做的好处是您可以卸载并重新安装新版本的软件，并且会自动将现有数据库升级到最新版本。安装，升级和维护是一个梦想。尽管如此，这对于更多“企业”系统来说不起作用。
您可以通过采用ADO.Net实体或其他类似实体框架（如Entity Spaces）来减少其中一些问题。这些是对象关系映射层。它们为数据库中的每个实体（表）自动生成类，包括每列的属性等。然后，它们允许您使用自定义逻辑扩展这些类。如果您可以摆脱存储过程中的业务逻辑，并将它们放入实体类中，那么它的好处是它们是强类型的。因此，如果您更改列的名称或删除列并重新生成实体类，那么IDE或编译器会自动标记代码被破坏的所有位置。显然，所有的实体代码自然也在源代码控制中，其余的源代码也是如此。
我见过源控制工作最适合在团队环境中的SQL Server的方式是当DBA没有定期使用数据库的建立签入代码。它通常只需要一个丢失事物的实例，因为在开发人员获取图片之前，它没有签入，因为检查他们的代码意味着什么。
希望这有助于
比尔
我曾在源代码控制是发布过程的一部分的环境中工作。
DBA被授予发行说明，要求DBA从源代码控制获取，然后从那里释放存储过程更改或SQL脚本。如果您可以将DBA放在一边，那么这是避免放弃版本的好方法，因为您应该能够在UAT系统上预先测试SQL。
如果数据没有发布到源代码管理中，那么它不会被释放。
集成分支用于释放代码。
我们一直使用SQL Server 2000附带的scptxfr实用程序将数据库脚本编写到存储在源代码管理下的文件中。
我们在做检查之前运行它，它会突出显示发生的任何机会（无论预期与否）。它不会在2005或更高版本中出现，但如果您有任何旧版本的2000年版本，它仍然可以对付新版本。它可能对复杂的模式有问题，但它是一个很好的起点。当与源控制触发器或持续集成结合使用时，它也可以成为自动过程。
关键是要限制只有少数人的权利，并坚持认为除了通过调用源代码管理脚本之外，他们不会进行更改。在最新版本的SQl Server中，您还可以设置DDL日志记录以准确找出将该表更改为不在源代码管理中的版本的人员！
当我们第一次切换到在我们的数据库上使用源代码控制时，每个人都拥有prod权限（我们已经固定），所以我们有一个dba定期比较源代码控制check in与实际prod数据库，并摆脱任何未经授权的更改。它只花了一次的时间来说服开发人员他们必须使用源代码管理。
红门SQL源代码控件将源代码管理完全集成到SQL Server Management Studio中。这有效地将您的开发数据库链接到您现有的源代码管理系统（TFS和SVN），只需点击一个按钮即可提交更改并检索其他开发人员的更改。
http://www.red-gate.com/products/SQL_Source_Control/
现在，我们已经加入VSS和SourceGear库支持的EA版本。更多细节在这里：http://www.red-gate.com/MessageBoard/viewtopic.php?t=12265
我最近写了一个脚本来帮助我们解决这个问题 - 它不是完全的源代码管理，它只是一个存储过程，它将数据库对象的历史存储在一张表中 - 你可以使用SQL代理将其安排为按需要运行。
虽然它会在某个时间点拍摄快照，但它并不真正支持签入，但是当存储的proc在没有备份的情况下被丢弃或更改时，它已经保存了几次培根，以前的版本很容易恢复。
http://trycatchfinally.net/2011/06/roll-your-own-lightweight-sql-server-source-control/
获得开发商要记得提交代码是棘手的。
它的另一端更容易一些，因为一旦更新在源代码管理中，它们可以通过脚本自动生成一个新的数据库/或者从源代码管理中删除并重新创建一个数据库。
看看这个免费的product这将有助于建立一个SQL Server数据库的基准。
该工具还将从源代码控制中构建数据库 - 因此从理论上说，您可以让X开发人员在项目中工作，并且他们都可以将其他源代码从源代码运行到自己的数据库中 - 反之亦然，他们的更新回到源代码控制。
不幸的是， - 我想不出如何让开发人员记得提交数据库更改。也许他们可以运行一个工具（或批处理文件），它将执行本地数据库拉到源代码控制，然后养成通过批处理文件运行这个重复任务的习惯 - 每次他们来做一个拉/提交源控制？
这是一个大问题，我问了很多时间，但没有很好的答案，唯一的答案似乎是通过操作程序来协调它。 – tekBlues 2009-07-01 14:26:35
由于这个原因，我们创建了http://tessik.com/sqlhistorian：依靠开发人员更新他们的版本控制以防止他们在数据库中执行的操作是徒劳的。一旦T-SQL击中服务器，我们的系统就会自动将更改记录到源控件，而无需任何其他用户交互。 – 2015-02-04 17:04:56
许多公司**不允许**开发人员直接将脚本应用到生产环境中，所以我认为最好的方案是允许（DBA）从脚本更新**到数据库**，而不是相反。但是，在现实世界中，有人可能没有正确地遵循变更程序，所以**最好是允许双向比较。试试这个免费工具：** [http://servantt.com]（http://servantt.com/?so） - 它允许你逆向工程你的对象，保存到脚本，比较数据库和脚本，启动WinMerge for比较，更新脚本或将更改应用到数据库。 – drizin 2016-01-28 21:05:45