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