Database design 在执行TDD和增量添加功能时，我是提前设计数据库还是在编码时添加表和列？

在我看来，TDD给我们提供的最重要的机会之一是逐步开发项目，一个接一个地添加功能，这意味着理想情况下，我们在每个时间点都有工作系统。
我想问的是，当项目涉及使用数据库时，我们可以使用这种增量方法来创建数据库结构，还是应该在开始编写代码之前先计算出结构？我知道很难预测一年后数据库的结构会是什么样子，但一般来说，它的最佳实践是什么？

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

您需要设计数据库结构。在某种程度上，TDD不是关于测试逻辑（头部的逻辑），而是关于测试实现，并确保它保持一致

设计数据库，就像设计任何东西一样，是要在逻辑上和概念上使其正确。也就是说，确保您有正确的字段，该表将是有用的，它确保并暗示了正确类型的关系，并且它允许您希望的所有类型的操作

因此，在编写任何代码之前，您需要有这个“东西”，以了解您的代码将做什么。因此，首先创建数据库，然后编写代码对其进行测试，这很简单

---

也许通过测试，你会发现你忘记了什么。好的，这是一个很好的例子；因此，返回并添加它，然后继续测试。

TDD和雅格尼的好处在于它明确地解决了我们作为开发人员无法预测未来需求的问题。这对于关系数据库设计和面向对象代码都是如此

---

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

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

从理论上讲，您可以在需要时添加一个列，并在运行过程中重构数据库，因为这是敏捷的

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

正如skaffman在评论中提到的：数据库维护通常比代码维护更昂贵。这一点在首次推出时更加正确：您可以顺利推出整个新应用程序，但可以尝试在不破坏数据的情况下规划实时数据库升级

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

架构师（或技术负责人，或首席DBA，或任何你喜欢的人）的角色是展望这几个月，规划你90%确信会发生的事情，其中一部分是定义你将需要的数据以及数据可能存在的位置

---

因此，与其一次添加一列，不如一次添加一个表。找到适合您的项目和开发过程的平衡点，而不需要加倍您的工作量。

如果您的表采用Boyce Codd标准格式或更好的格式，则任何应用程序都可以轻松地使用它们，而无需修改，假设它们实际存储了所需的数据。关系数据库和关系建模的要点是开发一个独立于任何应用程序的搜索路径或常用查询的数据模型

而且“提前”设计一个适当规范化的数据库非常容易，至少如果您知道提前管理的数据是什么

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

我们可以使用这种增量方法来创建数据库结构，还是应该在开始编写代码之前先计算出结构

是的，你可以（看看福勒的）。不，你不应该提前处理结构（这是BDUF）。Scott Ambler也写了很多关于这一点的文章，以及允许将其应用于真实场景的技术。打个比方，查克

---

正如我在评论中所说的，如果您的DBA不喜欢（如果他使用模型和数据，如Gollum和the precious），请另找一个DBA，一个了解Fowler和Ambler工作的DBA。可以采取几种方法来降低重构数据库以匹配TDD生成的代码的难度。考虑生成数据库作为从TDD过程的一部分创建的类。< /P> 另一种可能性是使用类似于的工具从概念数据库模型生成数据库、测试数据，甚至可能生成基本的存储库代码。这里的“ORM”是对象角色建模（“其他”ORM），而NORMA是一个VisualStudio插件，可以从概念模型生成DDL和代码

---

好的是，即使概念模型发生了显著的变化（例如，关系变得多对多），那么代码和DDL都会发生变化以反映这一点。

这里的区别是重构数据库通常比重构困难得多code@skaffman：有时可能更难。有时候不是。我的意思是，很明显，这不是真的