如何使用 VS 2005 对 SQL Server 架构进行版本控制？
我是 C# 编程新手，最近接触的是 Ruby on Rails。在 RoR 中，我习惯于为数据库编写架构迁移。我希望能够为我的 C#/SQLServer 项目做类似的事情。
VS 2005 工具集中是否存在这样的工具？
直接在 VS 2005 之外使用 SQL Server 进行 RoR 迁移是否明智？换句话说，我将使用 ActiveRecord:Migration from Rails 处理所有模式版本控制，但不会使用其他任何东西。
如果我确实使用其他工具处理 C# 和 VS 2005 之外的迁移，RoR ActiveRecord:Migration 是最好的选择还是有更合适的工具？
I am new to C# programming and am coming to it most recently from working with Ruby on Rails. In RoR, I am used to being able to write schema migrations for the database. I would like to be able to do something similar for my C#/SQLServer projects.
Does such a tool exist for the VS 2005 toolset?
Would it be wise to use RoR migrations with SQL Server directly outside of VS 2005? In other words, I would handle all schema versioning using ActiveRecord:Migration from Rails but nothing else.
If I do handle migrations outside of C# and VS 2005 with another tool, is RoR ActiveRecord:Migration the best thing to use or is there something which is a better fit?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果没有 VS Team Edition 的数据库版本，则没有内置方法可以执行此操作。我们使用与此类似的 NANT 脚本，并使用与 Ruby 类似的日期来为迁移文件添加日期。
http://www.bottleit.com.au/blog/帖子/连续数据库集成.aspx
There's no built in way of doing this without the Database Edition of VS Team Edition. We use a NANT script similar to this and date the migration files with a date similar to how Ruby does it.
http://www.bottleit.com.au/blog/post/Continuous-database-integration.aspx
我对 DBDeploy.NET 的处理感到满意我们的数据库版本控制。我当前的项目使用 C# + SQL 2008。DBDeploy 未集成到 Visual Studio 中，但我想您可以通过 IDE 中的一些自定义外部工具条目来实现它。
还有其他肯定有效的工具。我不熟悉 Ruby ActiveRecord:Migration，但如果您已经有使用这个特定工具的经验，为什么不坚持使用它呢？至于 Visual Studio 内部的数据库版本控制/迁移，我相信您将需要升级到数据库专业版（我上次检查的此版本需要额外费用）。
总之，我会按照你所知道的去做。恕我直言，大多数用于数据库版本控制的免费工具目前仍然有些不成熟。如果您想了解有关 DBDeploy.NET 的更多信息，您可以从原始项目中阅读它，该项目是从此处移植的 - http:// /dbdeploy.com/ 另外，请记住 DBDeploy 工具是跨平台的（支持许多数据库系统，而不仅仅是 SQL Server 和 Oracle）并且是开源的。
I have been happy with DBDeploy.NET for handling our database versioning. My current project uses C# + SQL 2008. DBDeploy is not integrated into Visual Studio but I suppose you could make it happen with some custom external tool entries in the IDE.
There are other tools out there that certainly work. I am not familiar with Ruby ActiveRecord:Migration but if you are already experienced in using this particular tool why not stick with it? As far as database versioning / migrations inside of Visual Studio I believe you will need to upgrade to the Database Professional Edition (extra cost for this version last I checked).
In summary, I would go with what you know. Most of the free tools for DB versioning are still somewhat half-baked at present IMHO. If you would like more information on DBDeploy.NET you can read up on it from the original project it was ported from here - http://dbdeploy.com/ Also, keep in mind that the DBDeploy tool is cross-platform (supports many DB systems, not just SQL Server & Oracle) and open-source.
对于分发应用程序，我最喜欢的方法实际上是内部构建的方法： 版本控制和您的数据库。
我使用数据库扩展属性来存储当前磁盘上部署的架构版本，然后运行一个内部升级数组，该数组维护磁盘上版本 => 之间的映射。将脚本升级到下一个版本。启动时，应用程序运行升级数组中的步骤，直到磁盘上的版本与当前应用程序版本匹配。因此，升级会经历所有中间版本。部署新站点（新位置）会经历每个架构版本，有时会创建和删除不再使用的对象。这可能看起来很奇怪，但最终应用程序可以部署在任何以前发布的版本上。如果客户有 3 年前的模式，每个人都忘记了它包含的内容，那么应用程序知道如何始终将其更新，这很棒。
与 diff 比较工具（例如 VS DB 项目集成）相比，我更喜欢这种方法，因为它是可测试的，并且可以更好地控制任何升级所采取的确切步骤。 Diff 工具会执行各种可疑的操作，例如复制表和重命名，这对于测量 +1TB 的部署（我的应用程序必须处理）不起作用。
如果您期望的数据大小相当小（<100 Gb），我会考虑基于差异的工具。基于 vsdbcmd 的 VS DB 项目部署在这种情况下可以正常工作。另外，如果您的部署目标只有一个位置（即只有一个目标的 Web 应用程序，即网站数据库），那么升级任何先前版本的能力就会失去吸引力。
For distributing application my favorite approach is actually one built in-house: Version Control and your Database.
I use the database extended properties to store the current on-disk deployed schema version, and then run an internal upgrade array that maintains a map between on-disk version => upgrade script to next version. At start-up, the app runs the steps in the upgrade array until the on-disk version matches the current app version. So an upgrade goes through all intermediate versions. Deploying a new site ( a new location) goes through every schema version, sometimes creating and dropping object no longer used. This may seem weird, but in the end the application can be deployed over any previously released version. If a client has a schema from 3 years ago everyone forgot what it contains, the app knows how to bring it up to date, always, which is great.
I favor this approach over diff compare tools (eg. VS DB project integration) because is testable and offer much better control over the exact steps taken on any upgrade. Diff tools do all sort of questionable actions, like copying tables and renaming, which doe snot work for deployments measuring +1TB (which my app has to deal with).
If the data size you expect is reasonable small (<100 Gb) I'd consider diff based tools. VS DB project deployment based on vsdbcmd works fine in such conditions. Also, if your deployment target is only one location (ie a web app where there is only one target, the web site db), then ability to upgrade any previous version looses it's appeal.
尝试使用 DBSourceTools。 http://dbsourcetools.codeplex.com
它是开源的，专门用于帮助开发人员对数据库进行版本控制。
Try DBSourceTools. http://dbsourcetools.codeplex.com
Its open source, and specifically designed to help developers version control databases.