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