如何将现有的 SQL Server 存储过程添加到源代码管理中？
现在，我们有一堆数据库服务器，其中运行着存储过程，但这些存储过程的文档记录很少，而且不存在于其他地方。
当对其中之一进行更改时，没有日志，并且很难弄清楚为什么正在运行的某些东西突然失败了。
我们最近转而使用 SVN 进行适当的版本控制，因此我希望将这些存储过程添加到版本控制中。
我们是一家 .Net 商店，我知道存在 Database 项目类型。这是一个好方法吗？
或者，我可以将存储过程保留为文本文件并对其进行操作，但我想知道这样做所涉及的烦人的部署步骤。
Right now we have a bunch of database servers with stored procedures running in them that are poorly documented and exist nowhere else.
When a change is made to one, there is no log, and it's really hard to figure out why something that was working suddenly fails.
We've recently switched to using proper version control using SVN, so I was hoping to add these stored procedures to version control.
We are a .Net shop, and I'm aware that there exists a Database project type. Would that be a good approach?
Alternatively I could just keep the stored procedures as text files and operate on those, but I'm wondering about the annoying deployment steps involved with doing so.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
查看 redgate 的 sql 源代码控制。它有一个内置于SSMS的接口，并且可以与SVN集成。
http://www.red-gate.com/products/ sql-development/sql-source-control/
Check out redgate's sql source control. It has an interface built into SSMS and can integrate with SVN.
http://www.red-gate.com/products/sql-development/sql-source-control/
在 Visual Studio 中，我创建了一个空项目并向其中添加了脚本。它是我的服务器架构解决方案的一部分。现在每个脚本都在源代码控制之下。我还添加了一个文件夹结构以尝试保持理智。当应用程序完成时，我们可能会在多个服务器模式下在源代码控制下拥有近 3000 个脚本。并不是说这是最好的，但它适用于我们的项目。该解决方案还有一个实用程序，它使用 SMO 实际运行/部署所有脚本，因此所有内容都包含在一个解决方案中。随附的屏幕截图显示了一些结构供您参考...
In Visual Studio, I created an empty project and added the scripts to it. Its part of my server schema solution. Now every single script in under source control. I also added a folder structure as well to try and keep the sanity. When the application is finished we will have probably close to 3000 scripts under source control under multiple server schemas. Not saying this is the best, but it is working for our project. The solution also has a utility which uses SMO to actually run/deploy all the scripts, so everything is contained in one solution. Screen shot attached showing some of the structure for your reference...
在我看来，数据库项目是一个不错的选择。您可以导入整个数据库，包括表、视图、存储过程等。Visual Studio 将使用此信息构建数据库的内存模型。
它可以将其用于多种目的，包括确保您的存储过程正确访问表。例如，它发现我试图将整数参数插入到smallint列中。
A database project is a good choice, in my opinion. You can import the entire database, including tables, views, stored procedures, etc. Visual Studio will use this information to build an in-memory model of the database.
It can use this for several purposes, including making sure your stored procedures are properly accessing the tables. For instance, it caught me trying to insert an Integer parameter into a smallint column.
是的，我会推荐一个数据库项目——您可以以任一方向同步数据库元素（表/存储过程等）：源文件到数据库，或数据库到源文件。
您可以首先创建一个空数据库项目，然后从现有数据库同步到您的项目，这会为您创建 .sql 创建脚本。
您也可以使用数据库项目来创建部署脚本。非常方便。
Yes, I would recommend a database project -- you can synchronize database elements (tables/stored procedures, etc...) in either direction: source files to DB, or DB to source files.
You could start by creating an empty database project, then syncing from the existing database(s) to your project, which creates the .sql create scripts for you.
And you can use the database project to create deployment scripts too. Very handy.
我们使用数据库项目并取得了良好的效果。项目中存在所有 DML（3000 多个项目）。
开发人员必须在源代码管理中对 DML 进行更改并将其签入，并且只有签入的内容才会被提升/部署。
我们的源代码管理是TFS，我注意到从VS界面删除procs并不总是在源代码管理中标记要删除的proc。不知道 SVN 用它做什么。
We use the database project and have good results with it. All DML exists in the project (3000+ items).
Developers must make changes to the DML in source control and check them in, and only what is checked in will be promoted/deployed.
Our source control is TFS, and I noticed that deleting procs from the VS interface does not always mark the proc for deleting in source control. Not sure what SVN does with it.