在进行TDD和增量添加功能时,我是提前设计数据库还是在编码时添加表和列?

的好处 TDD 和 亚格尼 它明确地解决了我们作为开发人员, 无法预测 未来需求。关系数据库设计和面向对象代码的设计同样如此。

数据库是一个实现细节。它的唯一目的是通过提供持久性服务来支持应用程序。如果你不知道三个月后你的代码会做什么,那么认为你知道数据库会是什么样子是虚幻的。

对我来说,这是一个有“理论”答案和“现实世界”答案的问题。

理论上,你可以在需要的时候添加一个列,并在需要时重构数据库,因为这很灵活。

在现实世界中,如果DBA因为您再次更改了模式而不得不每五分钟重新生成一次测试数据,那么他们将杀死您。在一个较小的项目中,你个人会厌倦花一半的时间维护一个不稳定的数据库。

正如斯卡夫曼在评论中所暗示的:数据库维护通常比代码维护更昂贵。推出时更是如此:您可以顺利推出一个全新的应用程序,但可以尝试在不破坏数据的情况下计划实时数据库升级。

这是一个艰难的讨论,因为敏捷纯粹主义者会坚持认为一切都应该“及时”完成。但是,就像大多数敏捷的事情一样,现实是 某人 需要展望下一个版本。优先级确实会改变,但如果对6个月后的产品外观没有一个模糊的想法,那么你就会遇到比开发方法更大的问题。。。

架构师(或技术负责人,或首席DBA,或任何你有兴趣的人)的角色是展望未来的几个月,并为你90%确信即将到来的事情做计划,其中一部分是定义你将需要的数据以及数据可能存在的地方。

因此,与其一次添加一列,不如一次添加表。在不使工作量加倍的情况下,找到适合您的项目和开发过程的平衡点。

我们可以使用这种增量方法来创建数据库结构吗?还是应该在开始编写代码之前先处理好结构?

是的,你可以(看看福勒的) Evolutionary Database Design )。不,你不应该在前面处理这个结构(这是BDUF)。Scott Ambler也写了很多关于这一点的文章,以及允许将其真正应用的技术。Chek out Agile Database Techniques , Refactoring Databases: Evolutionary Database Design 和 The Process of Database Refactoring: Strategies for Improving Database Quality 例如

正如我在评论中所说,如果你的DBA不喜欢(如果他像咕噜一样处理模型和数据),那就找另一个DBA,一个理解Fowler和Ambler工作的DBA。时期

如果您的表是Boyce Codd Normal Form或更好的表,那么假设它们实际上存储了所需的数据,那么任何应用程序都应该可以很容易地使用它们,而无需修改。关系数据库和关系建模的全部目的是开发一个独立于任何应用程序的搜索路径或常用查询的数据模型。

而且,“预先”设计一个适当规范化的数据库非常容易,至少如果您知道要预先管理的数据是什么的话。

您需要“重构”RDBMS模式的唯一原因是,如果最初的设计对任何有能力的人来说都是表面上不可接受的。现在,一些表空间或索引可能需要调整,但这与设计无关。

就我而言,这里的答案非常明显。

您可以设计数据库结构。在某种程度上,TDD不是测试逻辑(头脑中的逻辑),而是测试实现,并确保它保持一致。

设计数据库,就像设计任何东西一样,都是为了在逻辑和概念上使其正确。也就是说,确保你有正确的字段,确保表是有用的,确保并暗示正确的关系类型,并允许你想要的所有类型的操作。

所以,在你写任何代码之前,你需要有这个“东西”,才能知道你的代码会做什么。因此,你首先制作DB,然后编写代码来测试它。

也许通过测试,它会表明你忘记了什么。好吧,这是一个合适的;所以返回并添加它,然后继续测试。

可以采取几种方法来降低重构数据库以匹配TDD生成的代码的难度。考虑将创建的类作为TDD过程的一部分来生成数据库。

另一种可能性是使用以下工具从概念数据库模型生成数据库、测试数据,甚至可能生成基本的存储库代码 NORMA 这里的“ORM”是对象角色建模(“其他”ORM),NORMA是一个Visual Studio外接程序,可以从概念模型生成DDL和代码。

好的一面是,即使概念模型发生了重大变化(例如,一种关系变得多对多),代码和DDL也会发生变化以反映这一点。