在 Visual Studio 2008 中使用 sql server 2005 数据库项目的最佳实践
在 Visual Studio 2008 中使用“sqlserver 2005 数据库项目”的最佳实践是什么？
我已经创建了一个项目文件。 如何创建存储过程、视图和表的脚本？ 如何生成脚本来填充一些查找数据？
在数据库已部署到生产环境后，我该如何处理可能需要在生产服务器上运行的修改。 （我想我会创建由部署日期命名的文件夹，其中包含所有更改脚本）
有没有办法让 Team Build 拆除并重建数据库以测试所有脚本是否有效？
我在网上找不到步行路线。 如果您能指出正确的方向，我将不胜感激。
谢谢
what are the best practices for using the 'sqlserver 2005 database project' in visual studio 2008?
I have created a project file.
How to create the scripts for stored procedures, views and Tables?
How would I generate scripts to populate some of the look up data?
What would I do about modifications that may need to be run on the production server after the database has already been deployed to production. (I imagine that I would create folders named by the deploy date with all the change scripts )
Is there a way to have Team Build tear down and rebuild a database in order to test that all the scripts work?
I have not been able to find a walk threw on the web. If you could point me in the right direction, It would be greatly appreciated.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
无论技术如何，管理任何数据库生命周期的最佳实践是：
至少，您应该从自动构建中获得一些可以在生产服务器上运行而无需调整的东西，以便在升级程序时将数据库升级到新版本。 Ruby on Rails 迁移是一个很好的示例，说明了如何完成此操作。
不幸的是，SQL Server 2005 数据库项目采用了完全不同的方法，据我所知，这与这些原则完全不兼容。 他们确实提供“增量部署”，但似乎这完全基于模式比较工具。 模式比较作为一个起点很有用，但是有许多数据库重构是它们无法处理的，而且通常情况下，您将不得不调整它们（冗长的、难以理解的过程使这个过程变得更加困难）阅读它们生成的意大利面条代码。）
我写了一篇博客文章，其中我 更详细地检查这些问题。
The best practices for managing the lifecycle of any database, regardless of technology, are:
At the very least, you should get something out of your automated build that you can run, without tweaking, on your production server, to upgrade your database to the new version when you are upgrading your program. Ruby on Rails migrations are a good example of how it should be done.
Unfortunately, SQL Server 2005 database projects take a completely different approach, which, as far as I can see, is totally incompatible with these principles. They do offer "incremental deployment," but it seems that this is based entirely on schema comparison tools. Schema comparisons are useful as a starting point, but there are many database refactorings that they can not handle, and more often than not, you are going to have to tweak them (a process made all the harder by the long-winded, difficult to read, spaghetti code that they generate.)
I've written a blog post where I examine these issues in more detail.
我一般不使用VS中的数据库项目类型。 我最喜欢的处理数据库的工具是 Red Gate 的 SQL Compare ( SQL 数据比较也不错）。 脚本总是与质量保证/生产不同步，而这个工具将挽救你的生命（好吧，至少节省你的时间和理智）。
I don't generally use the database project type in VS. My most favorite tool for dealing with databases is Red Gate's SQL Compare (SQL Data Compare is also good). Invariably scripts get out of sync with qa/production and this tool will save your life (well, at least save you time and sanity).