对于那些敏捷从业者...
在项目期间如何管理对数据库模式的更改?我的假设是,在敏捷项目中,所涉及的任何数据库的架构都会发生变化并被重构,就像代码库一样。
这个假设正确吗?如果是这样,您是否有任何特定的工具或流程可以用来帮助保持事情顺利进行?
对于那些敏捷从业者...
在项目期间如何管理对数据库模式的更改?我的假设是,在敏捷项目中,所涉及的任何数据库的架构都会发生变化并被重构,就像代码库一样。
这个假设正确吗?如果是这样,您是否有任何特定的工具或流程可以用来帮助保持事情顺利进行?
AgileData.org是一个关于敏捷数据库开发的优秀资源——远远超过我塞进一个单一的回复。特别是,您可能对敏捷数据最佳实践感兴趣。如果您使用 SQL Server,您可能还对Red Gate软件中的 SQL Compare 感兴趣。我们的 DBA 使用它来帮助我将现有应用程序的更改从 QA 迁移到生产。
对于每次更新,我会:
高温高压
干杯,
抢
在我们的敏捷设置中,有一个用于数据库更改的文件夹,以 .SQL 文件的形式完成。到目前为止,我们在每个版本中都进行了数据库更改,并且该文件以应用程序版本命名。更新站点时,安装脚本会自动应用所有更改文件。
我们还有一个参考数据库的完整模式转储,用于新安装,由我们的数据库管理工具创建。
我知道有一些工具可以帮助自动化这个过程,比如 Red Gate,但是手动创建 SQL 更改文件非常容易。
理想情况下,您进行非破坏性更改,然后在发布完成后,您可以完全弃用架构的旧部分。这并不容易,需要纪律。这甚至并不总是可能的。
看看Ruby on rails 迁移。如果你不使用 Rails 也没关系,因为这个想法已经被复制到其他框架。
数据库结构很可能是代码的许多部分的依赖项,并且模式更改将产生级联效应。有点像在许多类扩展的类中更改接口。因此,请谨慎对待架构更改。
敏捷方法与其他方法没有什么不同,因为尽可能多地预先设计数据库对您有利,并且您应该寻求比代码更频繁地更改它。并不是说你永远无法改变它,但这样做代价高昂。
正如其他人所指出的,迁移是一种简单但有效的跟踪架构更改的工具。这个概念是 CREATE 和 ALTER 语句的脚本,用于从模式的一个修订版升级到下一个修订版,伴随着 ALTER 和 DROP 语句的脚本来降级相同的更改。Ruby on Rails 在此之上使用了一个数据库抽象层,以便更轻松地切换数据库品牌,但如果您只需要支持一个品牌,您可以简单地使用 SQL 文件。
有一本关于这个主题的备受推崇的书(虽然我还没有购买或阅读它),名为“重构数据库:进化数据库设计”,作者是 Scott Ambler