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

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

---

我不太熟悉的是在部署关系数据库后使用和更新它。我正在开发一个小的宠物项目，我计划在上面练习，我想知道我是否应该考虑在初始版本中不会使用的数据，但是在计划的特性列表中？添加表和调整模式是否与添加新类一样容易？或者我应该试着为我可以想象使用但近期不打算使用的东西设置表格吗？

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

我工作过的每一个基于DBMS的应用程序都定期更新scema，因此这应该在过程中进行规划。DBA不会喜欢您的提案中的“经常发布”部分，因为这对他们（如果是非DBA数据库，您也会喜欢）

---

但这就是他们的目的。

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

---

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

如果您对数据库进行了良好的测试，我会将YAGNI扩展到您的数据库设计中

---

一般来说，添加列和表很容易，删除或修改它们就不那么容易了。在设计表时要考虑到这一点（即，如果一个客户可以有多个用户，则不要将userid添加到客户表中。在第一次正确地添加用户id）。

这一原则仍然适用。在拥有大量数据之前，您不必担心向表中添加字段等。相当多的数据。因此，在没有看到实际数据的情况下过早地担心索引和查询计划的细节往往会浪费时间，甚至会导致以后的体系结构问题

不幸的是，如果不遵循良好的测试/发布流程，那么在产品发布后胡乱处理数据库设计可能会非常可怕。因此，与代码相比，您更希望在第一次使用数据库时就将其正确

对于数据库，您确实希望计划将数据取出、放入和存储，因此，如果您的“计划”功能包括报告，这将对数据库的设计产生很大影响，那么可以为此计划

调整模式不像添加类那么容易，但这是可行的

---

因此，总体而言，YAGNI仍然适用。

不要设置不需要的表格。雅格尼背后的部分原因是，你不会预先预测你需要的正确的东西。您可以在需要更改时轻松地添加新表、更改现有表等

---

一个好的框架应该有一些工具来执行，这些工具允许您轻松自动地升级和降级数据库。如果你已经准备好了，并且对你的设计相当谨慎，你应该能够按照你需要的方式进行重构，而不是试图提前提出你需要的所有东西。

关于数据库设计和实现，有很多敏捷的想法。你可能会有兴趣通过这本书来了解斯科特·安布勒对这个问题的一些想法。就我自己而言，我通常让数据库的设计随着应用程序的开发而增长。我很少提前创建表格。例外情况是审计和权限等贯穿整个设计的东西。我会考虑如何实现这些东西，即使我没有事先为它们创建任何表。横切方面确实会影响表的设计，即使这些特性并不总是最先出现的。

数据库设计与任何其他类型的设计一样。你的理解会逐渐增长，随着理解的加深，你会有一个不断发展的模式

我希望能够更容易地解释关系数据库模式设计的概念基础。唯一真正为其建模的工具是对象角色建模，它已经出现了很长一段时间。最熟悉的工具是Visiomodeler。为了了解它的味道，这里有一些到和的链接，但我们可以得出的结论是，对象建模类型断言直接导致特定的关系逻辑模型；因此，模式需要随着概念模型的更改而更改

实际上，如果您对转换表达式非常熟悉，您的rdbms可以处理相当多的灵活性；而且做得好是值得的

---

注意：我认为像LINQ和对象关系模型这样的SQL避免技术只会阻碍不断发展的设计。我可能错了。有理由希望微软的实体框架将包含对象角色建模；但我只看到过对这种可能性的间接引用。

数据库设计有一个概念基础

在经典的数据库设计中，有三种模型：概念模型、日志模型