在 Visual Studio 2008 中使用“sqlserver 2005 数据库项目”的最佳实践是什么?
我创建了一个项目文件。如何为存储过程、视图和表创建脚本?我将如何生成脚本来填充一些查找数据?
在数据库已经部署到生产环境后,我将如何处理可能需要在生产服务器上运行的修改。(我想我会使用所有更改脚本创建以部署日期命名的文件夹)
有没有办法让 Team Build 拆除并重建数据库以测试所有脚本是否正常工作?
我一直无法在网上找到散步。如果您能指出我正确的方向,将不胜感激。
谢谢
在 Visual Studio 2008 中使用“sqlserver 2005 数据库项目”的最佳实践是什么?
我创建了一个项目文件。如何为存储过程、视图和表创建脚本?我将如何生成脚本来填充一些查找数据?
在数据库已经部署到生产环境后,我将如何处理可能需要在生产服务器上运行的修改。(我想我会使用所有更改脚本创建以部署日期命名的文件夹)
有没有办法让 Team Build 拆除并重建数据库以测试所有脚本是否正常工作?
我一直无法在网上找到散步。如果您能指出我正确的方向,将不胜感激。
谢谢
我一般不使用VS中的数据库项目类型。我最喜欢处理数据库的工具是Red Gate 的 SQL Compare(SQL Data Compare 也不错)。脚本总是与 qa/production 不同步,而这个工具会挽救你的生命(嗯,至少可以节省你的时间和理智)。
无论采用何种技术,管理任何数据库生命周期的最佳实践是:
至少,您应该从您的自动化构建中获得一些可以在您的生产服务器上运行而无需调整的东西,以便在升级程序时将您的数据库升级到新版本。Ruby on Rails 迁移是一个很好的例子,说明了它应该如何完成。
不幸的是,SQL Server 2005 数据库项目采用了完全不同的方法,据我所知,这与这些原则完全不兼容。他们确实提供“增量部署”,但似乎这完全基于模式比较工具。模式比较作为一个起点很有用,但有许多数据库重构它们无法处理,而且通常情况下,您将不得不对它们进行调整(由于冗长、难以阅读他们生成的意大利面条代码。)
我写了一篇博文,我在其中更详细地研究了这些问题。