YAGNI是否适用于数据库设计？

Question

在代码中，通常很容易添加新的类来提供额外的功能等等。我对重构代码和涉及到的内容有相当好的理解，所以YAGNI对我来说通常是有意义的。

我不太熟悉的是关系数据库在部署后的使用和更新。我正在开发一个小项目，我计划在上面练习Release Early, Release Often，我想知道我是否应该考虑在初始版本中不会使用的数据，但在计划的功能列表中？添加表和调整模式是否像添加新类一样容易？或者我应该尝试为我可以想象到的使用的东西建立表，但不打算在不久的将来这样做？

Answer 1

如果你有很好的数据库测试，我会将YAGNI扩展到你的数据库设计中。

通常，添加列和表很容易，但不太容易显著地删除或修改它们。在设计表时要考虑到这一点(即，如果客户可以有多个用户，则不要将userid添加到customers表中。第一次就做对了)。

Answer 2

这是一个很好的问题。我个人发现，修改数据库模式并将所有数据转换为新的表示形式要比重构代码困难得多。事实上，每当我开始一个将使用新数据库的项目时，我总是在坐下来编写任何代码以尽可能彻底地完成我的规范之前花费时间。这通常需要预测特性并将对它们的支持合并到数据库中，即使我不打算立即实现它们。

如果您使用框架或其他类似的层来提供更改数据库的机制，那么您可以在数据库重构方面更灵活一些，但如果您直接编写SQL，那么我建议您投入一定的时间来设计和实现一个将来不太可能需要更改的模式。

Answer 3

我的观点是YAGNI适用于一切，编码、数据库设计、家务活(我妻子在这一点上强烈反对我)，等等。

我工作过的每个基于DBMS的应用程序都定期更新scema，所以这应该在进程中进行计划。DBA不会喜欢您的提案中的“经常发布”部分，因为这对他们来说是更多的工作(如果是非DBA数据库，则是您的工作)。

但这就是他们在那里的目的。