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

Question

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

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

Answer 1

这是一个很好的问题。我个人发现修改数据库模式并将所有数据转换为新表示比重构代码要困难得多。事实上，每当我启动一个将使用新数据库的项目时，我总是需要时间，然后我坐下来编写任何代码以尽可能详细地获取我的规范。通常需要的是预测功能并将对它们的支持纳入数据库，即使我不打算立即实现它们。

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

Answer 2

我的观点是，YAGNI适用于所有事物，编码，数据库设计，在房子周围工作（我的妻子在这个问题上强烈反对我），等等。

我曾经参与过的每个基于DBMS的应用程序都经常对scema进行更新，因此应该在流程中进行规划。 DBA不会喜欢您的提案中的“经常发布”部分，因为这对他们来说是更多的工作（或者如果它是非DBA数据库的话）。

但那就是他们的目的。

Answer 3

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

通常，添加列和表很容易，并且不太容易删除或显着修改它们。在设计表时考虑到这一点（即，如果客户可以拥有多个用户，请不要将userid添加到customers表中。第一次就做好。）

Answer 4

对数据库设计和实现有一整套敏捷的思考。您可能有兴趣浏览best practices www.agiledata.org以了解Scott Ambler关于此主题的一些想法。对我自己而言，我通常会随着应用程序的发展而增加数据库的设计。我很少提前创建表格。例外情况就是审计和权限，以及贯穿整个设计的事情。即使我没有事先为它们创建任何表，我也会考虑如何实现这些东西。交叉方面确实会影响表格的设计，即使这些特征并不总是第一个出门的。

Answer 5

数据库设计有概念基础。

在经典数据库设计中，有三种模型：概念，逻辑和物理。

概念模型来自需求分析，随着基础主题的演变或对主题的理解的演变而演变。概念模型将基本数据定义为形式和语义，但不处理表格组合等问题。

逻辑模型使用数据的关系模型。它可以从概念模型中推导出来，但它也涉及关系的组成。规范化和其他组成问题在这里发挥作用。逻辑模型预测表设计，以及应用程序将进行的查询和更新。

物理模型将关系实现为表，并且还添加了实际构建数据库所需的所有其他功能，如索引，表空间等。它来自逻辑模型，但数据量，负载，性能和磁盘空间都发挥作用。

这听起来冗长而乏味，但如果你知道怎么做，它实际上很快。整个过程可以在几周内完成，而团队的其他成员仍然在讨论功能规格。对于一个非常小的项目（6个表，50列），它可以在几天内完成，只需铅笔和纸。对于大型项目，有一些工具可以使设计更加自动化，更不容易出错，并且可以轻松绘制图表。

但是当您发现概念模型不准确或不完整，而其他两个模型和数据库本身需要更改时会发生什么？这就是Data Independence来救援的地方。数据独立性对数据库设计有什么封装对对象设计的作用。也就是说，它可以防止一个地方的微小调整在整个应用程序对象上传播。对象仅依赖于它们使用的数据。

如果必须将新表添加到模式中，任何应用程序被破坏的可能性都会非常小。即使必须更改现有表，仅使用旧列的查询也不会发现任何差异。即使对象依赖于更改，您仍然可以为更改的表提供新名称，然后使用旧名称创建一个视图，使其看起来仍然存在旧表。

在良好的DBMS中，物理数据独立性几乎已经完成。您可以重新组织数据，添加和删除索引等，您不必更改任何应用程序。

简而言之，使用非常好的DBMS产品可以很好地完成变更管理。不幸的是，许多DBA和程序员不知道如何充分利用这些DBMS功能，即使它们已存在多年。

Answer 6

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

不幸的是，如果没有遵循良好的测试/发布流程，那么在生产发布后滥用数据库设计可能会非常可怕。因此，除了代码之外，您还希望第一次使用数据库。

对于数据库，您确实希望计划将数据输出并将其存储并存储，因此如果您的“计划”功能包括报告，那么这将对数据库的设计产生很大影响，因此可能需要计划为此。

调整架构并不像添加类那么容易，但它是可行的。

总的来说，YAGNI仍然适用。

Answer 7

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

一个好的框架应该有一些用于执行migrations的工具，它们允许您轻松自动地升级和降级数据库。如果你有这个，并且对你的设计非常谨慎，你应该能够重构你所需要的方式，而不是试图想出你以前需要的一切。

Answer 8

数据库设计就像任何其他类型的设计一样。您的理解会逐渐增加，并且随着更好的理解，会有一个不断发展的架构。

我希望更容易解释实际上关系数据库模式设计的概念基础。真正模拟它的唯一工具是对象角色建模，它已经很长时间了。最熟悉的工具是Visiomodeler。为了得到它的味道，这里有一些指向Scott Ambler和Scot Becker的链接但是得出的结论是对象建模类型的断言直接导致特定的关系逻辑模型;因此，随着概念模型的变化，架构将需要改变。

在实践中，如果你对转换表达式非常熟悉，你的rdbms可以处理相当多的弯曲;并且值得擅长它。

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