敏捷开发和数据库更改

Question

那些敏捷的从业者......

如何在项目期间管理对数据库模式的更改？我的假设是，在敏捷项目中，所涉及的任何数据库的模式都会发生变化，并且会像代码库一样重构。

这个假设是否正确？如果是这样，您是否拥有用于帮助保持平稳运行的特定工具或流程？

Answer 1

AgileData.org是一个很好的资源 - 远远超过我对敏捷数据库开发的单一响应。特别是，您可能对Agile Data Best Practices感兴趣。如果您使用SQL Server，您可能也会对Red Gate软件中的SQL Compare感兴趣。我们的DBA使用它来帮助我将现有应用程序的QA更改迁移到Production。

Answer 2

对于每次更新，我都会：

• 部署前滚和回滚脚本，
• 部署“从头开始构建数据库”脚本，
• 部署数据迁移脚本和
• 强制执行一种机制，将代码锁定到数据库版本，即测试返回当前版本数据库的值，如果存在不匹配，系统会对不匹配进行大肆宣传和惨淡处理。

HTH

欢呼声，

罗布

Answer 3

在我们的Agile设置中，有一个用于DB更改的文件夹，以.SQL文件的形式完成。到目前为止，我们已经在每个版本中更改了数据库，并且该文件以应用程序版本命名。更新站点时，安装脚本会自动应用所有更改文件。

我们还有一个参考数据库的完整模式转储，用于新安装，由我们的数据库管理工具创建。

我知道有一些工具可以帮助自动执行此过程，例如Red Gate，但手动创建SQL更改文件非常容易。

Answer 4

理想情况下，您可以进行非中断更改，然后在发布完成后，您可以完全弃用模式的旧部分。这并不容易，需要纪律处分。它甚至不可能。

Answer 5

看看Ruby on rails migrations。如果你不使用Rails并不重要，因为这个想法已经被复制到其他框架了。

Answer 6

数据库结构很可能是代码的许多部分的依赖关系，并且架构更改将具有级联效果。有点像在许多类扩展的类中对接口进行更改。所以要对模式更改保持谨慎。

敏捷方法与其他方法没有什么不同，因为尽可能地预先设计数据库对您有利，并且您应该比代码更频繁地尝试更改它。并不是说你永远无法改变它，但这样做成本很高。

正如其他人所指出的，迁移是一种简单但有效的跟踪架构变更的工具。概念是CREATE和ALTER语句的脚本，用于从架构的一个版本升级到下一个版本，伴随着ALTER和DROP语句的脚本来降级相同的更改。 Ruby on Rails在此基础上使用数据库抽象层，以便更容易切换数据库品牌，但如果您只需要支持一个品牌，则只需使用SQL文件即可。

关于这个主题的一本备受推崇的书（虽然我还没有购买或阅读它）被Scott Ambler称为“Refactoring Databases: Evolutionary Database Design”