对于那些敏捷开发人员...敏捷开发和数据库更改
如何在项目中管理对数据库模式的更改?我的假设是,在敏捷项目中,涉及的任何数据库的模式都会随着代码库的变化而重构。
这个假设是否正确?如果是这样,您是否有任何特定的工具或流程用于帮助保持流畅运行?
对于那些敏捷开发人员...敏捷开发和数据库更改
如何在项目中管理对数据库模式的更改?我的假设是,在敏捷项目中,涉及的任何数据库的模式都会随着代码库的变化而重构。
这个假设是否正确?如果是这样,您是否有任何特定的工具或流程用于帮助保持流畅运行?
AgileData.org对于敏捷数据库开发来说,这是一个很好的资源 - 远远超过我对单个响应的压缩。特别是,您可能对Agile Data Best Practices感兴趣。如果您使用SQL Server,您可能也会对Red Gate软件中的SQL Compare产生兴趣。我们的数据库管理员使用它来帮助我将现有应用程序的变更从QA迁移到生产。
@redGate对于dba非常方便。 – dove 2008-12-02 14:45:06
我们已经在使用Red Gate的ANTS,并且对它非常满意,所以我一定会检查一下SQL Compare。感谢tvanfosson! – 2008-12-02 14:46:52
理想情况下,您可以进行不中断的更改,然后在发布完成后,可以完全弃用架构的旧部分。这并不容易,需要纪律。这甚至不可能。
看看Ruby on rails migrations。不要紧,如果你不使用Rails,因为这个想法已经被复制到其他框架。
在我们的敏捷设置中,有一个用于更改数据库的文件夹,以.SQL文件形式完成。到目前为止,我们在每个版本中都进行了数据库更改,并且该文件以应用程序版本命名。安装脚本在更新站点时自动应用所有更改文件。
我们还有一个参考数据库的完整模式转储,用于由我们的数据库管理工具创建的新安装。
我知道有些工具可以帮助自动执行此过程,例如Red Gate,但手动创建SQL更改文件非常简单。
每次更新时,我会:
HTH
欢呼声,
罗布
数据库结构是最有可能是你的代码的很多地方的依赖性和模式的变化将有连锁效应。有点像对许多类扩展的类中的接口进行更改。因此,谨慎对待模式更改。
敏捷方法与其他方法没有区别,因为尽可能多地设计数据库对您有益,您应该尽量不要频繁更改代码。并不是说你永远不能改变它,但这样做成本很高。正如其他人已经注意到的,迁移是跟踪模式变化的简单而有效的工具。这个概念是CREATE和ALTER语句的脚本,从架构的一个版本升级到下一个版本,伴随着ALTER和DROP语句的脚本以降级相同的更改。 Ruby on Rails在此基础上使用数据库抽象层,以便更换数据库品牌,但如果只需要支持一个品牌,则可以简单地使用SQL文件。
由Scott Ambler的“Refactoring Databases: Evolutionary Database Design”
几年后,有关于这个问题备受推崇的书(虽然我还没有得到解决,以购买或阅读它尚未)调用,我已经使用了巨大的成功[ Code First Entity Framework Migrations](http://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/migrations-and-deployment-with-the-entity-framework在一个asp-net-mvc-应用程序)来实现这一点! – 2016-03-08 15:41:13