从我的角度来看，TDD给我们提供的最重要的机会之一是逐步开发项目，逐个添加功能，这意味着我们在每个时间点都有工作系统。我问的是，当项目涉及数据库工作时，我们可以使用这种增量方法来创建数据库结构，还是应该在开始编写代码之前使用该结构？我知道很难预测数据库结构将在1年后开始，但一般情况下，它的最佳实践是什么？
答案 0 :(得分：8)
TDD 和 YAGNI 的好处在于它明确解决了我们作为开发人员无法预测未来需求的问题。对于关系数据库设计而言，这与面向对象的代码一样正确。
数据库是一个实现细节。它的唯一目的是通过提供持久性服务来支持应用程序。如果你不知道你的代码将在三个月之后做什么，那么认为你知道你的数据库会是什么样子将是不切实际的。
答案 1 :(得分：6)
对我而言，这是一个带有“理论”答案和“现实世界”答案的问题。
理论上，您可以根据需要随时添加一列，并随时重构数据库，因为它非常敏捷。
在现实世界中，如果他们必须每五分钟重建一次测试数据，那么您的DBA会因为您再次更改架构而终止您。在一个较小的项目中，你会因为不得不花一半时间维护一个不稳定的数据库而感到厌倦。
正如skaffman在评论中提到的：数据库维护通常比代码维护更昂贵。这对于部署来说是双重的：您可以毫不费力地滚动整个新应用程序，但尝试计划实时数据库升级而不会破坏您的数据。
这是一个艰难的讨论，因为敏捷的纯粹主义者会坚持认为一切都应该“及时”完成。但是，就像大多数事情敏捷一样，现实是某人需要在下一个版本之前展望。优先事项确实发生了变化，但如果在6个月内对产品的外观至少没有模糊的概念，那么你就会遇到比开发方法更大的问题......
建筑师（或技术主管，或首席DBA，或任何你喜欢的风格）的角色是展望未来几个月并计划你90％肯定即将到来，其中一部分将是定义您将需要的数据以及可能存在的数据。
因此，也许不是一次添加一列，而是一次添加一个表。找到适合您的项目和开发过程的平衡，而不会使您的工作量增加一倍。
答案 2 :(得分：5)
我们可以使用这种增量方法来创建数据库结构，还是应该在开始编写代码之前解决结构问题呢？
是的，你可以（看看福勒的Evolutionary Database Design）。不，你不应该预先在结构上工作（这是BDUF）。 Scott Ambler也写了很多关于这个以及允许在真实中应用它的技术。谢谢Agile Database Techniques，Refactoring Databases: Evolutionary Database Design和The Process of Database Refactoring: Strategies for Improving Database Quality。
正如我在评论中所说的那样，如果你的DBA不喜欢（如果他使用像Gollum这样的模型和数据与宝贵的一起），那就得到另一个DBA，一个了解Fowler和Ambler工作的DBA。周期。
答案 3 :(得分：3)
如果您的表格是Boyce-Codd Normal Form或更好，那么它们应该很容易被任何应用程序使用而无需修改，假设它们实际存储了所需的数据。关系数据库和关系建模的关键在于开发独立于任何应用程序的搜索路径或常用查询的数据模型。
至少如果您知道预先管理的数据是什么，那么“预先设计正确规范化的数据库”非常容易。
您需要“重构”RDBMS架构的唯一原因是，如果原始设计对于任何有能力的眼睛都是不可接受的。现在，可能需要调整一些表空间或索引，但这与设计无关。
答案 4 :(得分：1)
就我而言，这里的答案非常明显。
您设计数据库结构。 TDD在某种程度上不是测试逻辑（头脑中的逻辑），而是测试实现，并确保它保持一致。
设计数据库与设计任何内容一样，是在逻辑上和概念上使其正确。即确保您拥有正确的字段，表格将有用，它确保并暗示正确的关系类型，并允许您希望的所有类型的操作。
因此，在编写任何代码之前，您需要拥有此“东西”，以了解代码将执行的操作。因此，简单地说，您首先创建数据库，然后编写代码来测试它。
也许会通过测试证明你忘记了什么。好的，这很合适;所以回去添加它，然后继续测试。
答案 5 :(得分：0)
可以采取几种方法来降低重构数据库以匹配TDD生成的代码的难度。考虑从您创建的类中生成数据库，作为TDD过程的一部分。
另一种可能性是使用像NORMA这样的工具从概念数据库模型生成数据库，测试数据甚至基本存储库代码。这里的“ORM”是对象角色建模（“其他”ORM），NORMA是一个Visual Studio加载项，可以从概念模型生成DDL和代码。
好消息是，即使概念模型发生显着变化（例如，关系变为多对多），代码和DDL也会发生变化以反映出来。