che*_*r89 24 tdd database-design
从我的角度来看,TDD给我们提供的最重要的机会之一是逐步开发项目,逐个添加功能,这意味着我们在每个时间点都有工作系统.
我要问的是,当项目涉及数据库工作时,我们是否可以使用这种增量方法来创建数据库结构,还是应该在开始编写代码之前解决结构问题？我知道很难预测1年后数据库的结构会是什么样的,但一般来说,最好的做法是什么呢？
TDD和YAGNI的好处在于它明确地解决了我们作为开发人员无法预测未来需求的问题.对于关系数据库设计而言,这与面向对象的代码一样正确.
数据库是一个实现细节.它的唯一目的是通过提供持久性服务来支持应用程序.如果你不知道你的代码将在三个月后做什么,那么认为你知道你的数据库将会是什么样子将是不切实际的.
对我来说,这是一个带有"理论"答案和"现实世界"答案的问题.
从理论上讲,您可以根据需要随时添加列,并在进行时重构数据库,因为它非常灵活.
在现实世界中,如果他们每五分钟重建一次测试数据,您的DBA会因为您再次更改架构而终止您.在一个较小的项目中,你会因为不得不花一半时间来维护一个不稳定的数据库而感到厌倦.
正如skaffman在评论中提到的:数据库维护通常比代码维护更昂贵.这对于部署来说是双重的:您可以毫不费力地滚动整个新应用程序,但尝试计划实时数据库升级而不会破坏您的数据.
这是一个艰难的讨论,因为敏捷的纯粹主义者会坚持认为一切都应该"及时"完成.但是,就像大多数事情敏捷一样,现实是有人需要在下一个版本之前展望.优先事项确实发生了变化,但如果在6个月内对产品的外观至少没有模糊的概念那么你就会遇到比开发方法更大的问题......
建筑师(或技术主管,或首席DBA,或任何你喜欢的风格)的角色是展望未来几个月并计划你90%肯定即将到来,其中一部分将定义你的数据需要以及它可能存在的地方.
因此,也许不是一次添加一列,而是一次添加一个表.找到适合您的项目和开发过程的平衡,而不会增加您的工作量.
我们可以使用这种增量方法来创建数据库结构,还是应该在开始编写代码之前将结构工作？
是的,你可以(看看福勒的进化数据库设计).不,你不应该预先在结构上工作(这是BDUF).Scott Ambler也写了很多关于这个以及允许在真实中应用它的技术.挖掘敏捷数据库技术,重构数据库:进化数据库设计和数据库重构过程:例如,提高数据库质量的策略.
正如我在评论中所说,如果你的DBA不喜欢(如果他使用像Gollum这样的模型和数据与宝贵的一起),那就得到另一个DBA,一个了解Fowler和Ambler工作的DBA.期.