答复: 如何在敏捷开发中进行数据库设计

前面各位讲了很多巧妙、聪明的办法来适应不断变化的需求，很好，都是不错的经验。
但是我想说，在上帝面前，在未来面前，人类永远不够聪明。

楼主之所以格外的担心数据库结构发生变化，主要是因为一处变化会导致表结构、建表脚本、领域模型至少3处修改。
这个问题的解决方式就是定义领域模型并自动生成关系模型，以后变化时只需维护领域模型。
反过来，定义关系模型并自动导出领域模型也可以，但实际使用中我倾向于前一种做法，原因有很多：领域模型表现力更强更自然、我不喜欢自动生成的java代码、自动生成的代码无法维护和增强（因为下次生成时会被覆盖）、我不喜欢使用SQL（至少不喜欢DDL）。
但是对于很多大型项目由于各种原因采用了以关系模型建模的方式，这招就不灵了。

另外一个担心可能是对已上线系统存在大量数据的情况下难以修改数据库结构。
解决这个问题除了采用前面那些聪明的办法以外，还有一个思路——在系统投产之前就把系统做的尽可能成熟：
系统投产前我们可以毫无顾及的改表结构，那些真正敏捷的团队会通过更多的短小迭代、频繁的用户演示、频繁的用户沟通和反馈、极高的开发质量和开发效率、各种类型高强度的测试，把系统现有范围的功能做的尽可能的成熟，极大的降低了系统上线后需要修改现有表结构的几率。
现有需求有了足够成熟的实现，上线后的修改基本都是全新的需求，而全新的需求应该不需要改动现有表。