SQL Server DDL 代码的版本控制
我想要 CVS 下的所有DB DDL 代码。
我们对 .NET 代码使用 Subversion，但所有数据库代码仍然没有版本控制。
我们只知道数据库逻辑有多重要。我用谷歌搜索过，但只找到了很少的（昂贵的工具）。我相信存在其他（更便宜的）解决方案。
您建议采用什么方法？什么工具最合适？
SQL Server 2005、VS 2008 TS、TSVN
更新 我们的编码场景是开发人员无法直接访问PROD DB。它仅由脚本更改（因此这不是问题）
我最感兴趣的是所有开发人员都具有完全访问权限的 DEV 环境。
因此，开发人员会覆盖之前由其他开发人员更改的 USP。
我希望能够恢复丢失的版本/比较 USP 修订版等。
UPDATE-2
为了创建部署脚本，我们使用 Red-Gate SQL Compare。
工作完美 - 所以部署脚本不是一个案例。
I'd like to have all DB DDL code under CVS.
We are using Subversion for our .NET code but all database code remains still unversioned.
All we know is how important DB logic can be. I've googled but I've found only few (expensive tools). I believe there exists other (cheaper) solution(s).
What approach do you advise to follow? What tools are most appropriate?
SQL Server 2005, VS 2008 TS, TSVN
UPDATE
Our coding scenario is that developers cannot access to PROD DB directly. It is changed only by scripts (so this is not a problem)
I'm mostly interested in the DEV environment where all of developers have full access.
So it happens that a developer overwrite USP previously changed by another.
I'd like to have the possibility to restore lost version / compare USPs revisions etc.
UPDATE-2
To create deployment script we are using Red-Gate SQL Compare.
Works perfectly - so deployment scripts are not a case.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我编写了 SMOscript ，它为数据库中的每个对象生成一个 CREATE 脚本。
使用此工具生成 CVS 覆盖的目录，并更新您的存储库。
I wrote SMOscript which generates a CREATE script for each object in a database.
Use this tool to generate into a directory covered by CVS, and update your repository.
最后我发现这个工具和方法非常有用并且很容易引入
（至少在开始时 - 没有版本控制解决方案的地方）：
http:// www.codeproject.com/KB/database/SQLScripter.aspx
您可以开箱即用地运行它。
对于最终的解决方案，我倾向于 GDR。
Finally I found this tool and approach extremely useful and very easy to introduce
(at least at the beginning - where no versioning solution on the place):
http://www.codeproject.com/KB/database/SQLScripter.aspx
You can run it out of the box.
For final solution I'd incline to GDR.
这听起来也很有趣：
免费软件：
http://dbsourcetools.codeplex.com/
http://www.codeproject.com/KB/database/ScriptDB4Svn.aspx
http://www.codeproject.com/KB/database/SQLScripter.aspx
http://blog.boxedbits.com/archives/133
商业：
http://www.nobhillsoft.com/Randolph.aspx
This also sounds interesting:
Freeware:
http://dbsourcetools.codeplex.com/
http://www.codeproject.com/KB/database/ScriptDB4Svn.aspx
http://www.codeproject.com/KB/database/SQLScripter.aspx
http://blog.boxedbits.com/archives/133
Commercial:
http://www.nobhillsoft.com/Randolph.aspx
您应该使用 Management Studio (SSMS) 并将 .sql 置于源代码控制下，可能将单独的架构对象置于文件夹下。
希望这有帮助
You should use Management Studio (SSMS) and place the .sql under source control, possibly separate schema objects under folders.
Hope this helps
查看 Wizardby 是否满足您的需求。
See if Wizardby fits your needs.
如果您还没有读过，Martin Fowler 的文章进化数据库设计是一个很好的地方开始。
这篇文章很难概括，但它描述了他的团队如何在快速变化的开发过程中处理数据库版本控制。他们创建了自己的工具来简化事情：将用户带到当前主版本的脚本，复制模式的任何版本以便用户可以调试彼此的工作副本等。
对于一种可靠的低技术解决方案，我发现在源代码管理中保留两种 DDL 脚本很有帮助：
它们在某种程度上是多余的，但非常有用（特别是在部署方面）。
If you haven't already read it, Martin Fowler's article Evolutionary Database Design is a great place to start.
The article is hard to summarize, but it describes how his team dealt with database versioning in a rapidly changing development process. They created their own tools to facilitate things: scripts to bring users up to the current master, to copy any version of the schema so users could debug one another's working copies, etc..
For a solid low-tech solution, I've found it helpful to keep two kinds of DDL scripts in source control:
They're redundant to a degree, but extremely useful (particularly when it comes to deployment).
如果您还没有查看过 Visual Studio Database Edition GDR（又名“Data Dude”），那么您绝对应该下载它并尝试一下：
http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9- b1c9-8f55759846ed&displaylang=en
除此之外，GDR 将让每个开发人员轻松维护自己的数据库本地副本、版本脚本、创建部署脚本以将数据库架构移动到新版本，甚至支持数据库回滚。
如果您使用的是团队系统开发者版，它是免费的。一探究竟。
If you haven't already looked at the Visual Studio Database Edition GDR (a.k.a. "Data Dude"), you should definitely download it and try it out:
http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en
Among other things, the GDR will facilitate team development by making it easy for each developer to maintain their own local copy of a database, version scripts, create deployment scripts to move a database schema to a new version, and even support database rollback.
It's free if you are using team system developer edition. Check it out.
如果您使用的是 Visual Studio Team Suite 或 Visual Studio Developer Edition，您有权获得 Visual Studio Database Professional 的副本。这旨在完全按照您所描述的方式进行操作，甚至更多。我们用它来管理我们的数据库模式（代码）。
兰迪
If you are using Visual Studio Team Suite or Visual Studio Developer Edition, you are entitled to a copy of Visual Studio Database Professional. This is designed to do exactly what you describe, and much more. We use it to manage our database schema (code).
Randy
我们也将 Subversion 用于所有数据库代码。由于除非是在脚本中，否则任何内容都不允许进入 Prod，因此让人们将所有脚本放入 subversion 似乎没有问题。我们倾向于编写更改表脚本来更改具有现有数据的表，然后重新创建整个表结构，以防我们需要从头开始创建新数据库（我们通常在多个服务器上拥有相同的数据库结构，因为我们的一些客户端非常大并且不希望他们的数据意外地可供竞争对手使用，因此需要为单独的服务器付费，因此可能需要在没有数据的情况下再次创建整个数据库。）对于不直接存储数据的对象，我们删除原始对象并重新创建它创建语句。每个项目在存储库中都有自己的家，每个数据库也是如此，因此脚本可能位于多个位置以方便部署。
但真正的关键是，没有脚本，任何人都无法加载到 Prod。我们没有给予我们的开发人员直接的生产权限，因此与使用 SSMS 相比，他们在脚本中执行操作没有问题。
We use Subversion for all our database code as well. Since nothing is allowed to go to Prod unless it is in a script, there seems to be no porblem with getting people to put all the scripts into subversion. We tend to write alter table scripts to change tables with existing data and then recreate the whole table structure in case we need to create a new database from scratch (we often have the same database structure on multiple servers as some of our clients are very large and do not want their data accidentally available to the competition and so pay for separate servers and therefore may need to create the whole database again with no data.) For objects that don't directly store data we drop the orginal object and recreate it with a create statement. Each project has it's own home inthe repository and each database does too, so the script may be in more than one place to facilitate deployment.
But the real key is that no one can load to Prod without a script. We don't give our devs direct rights to prod, so they have no problem doing things in scripts as opposed to using SSMS.