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

Question

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

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

Answer 1

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

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

Answer 2

我的观点是 YAGNI 适用于一切，编码、数据库设计、在家工作（我妻子在这方面强烈反对我）等等。

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

但这就是他们的目的。

Answer 3

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

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

Answer 4

关于数据库设计和实现有很多敏捷思考。您可能有兴趣浏览 www.agiledata.org 上的最佳实践，了解 Scott Ambler对此主题的一些想法。就我自己而言，我通常让数据库的设计随着应用程序的发展而增长。我很少提前创建表格。例外情况是审核和权限之类的事情，这些事情会贯穿整个设计。即使我实际上并没有预先为它们创建任何表，我也会考虑如何实现这些东西。横切方面确实会影响表格的设计，即使这些功能并不总是最先出现的。

Answer 5

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

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

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

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

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

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

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

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

在一个好的 DBMS 中，物理数据的独立性几乎是完全的。您可以重新组织数据、添加和删除索引等，并且您不必更改任何应用程序。

简而言之，使用真正优秀的 DBMS 产品可以出色地完成变更管理。不幸的是，许多 DBA 和程序员不知道如何充分利用这些 DBMS 特性，即使它们已经存在多年。

Answer 6

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

不幸的是，如果不遵循良好的测试/发布过程，在产品发布后对数据库设计进行修改可能会非常可怕。因此，比代码更重要的是，您希望在第一次使用数据库时就将其做好。

对于数据库，您确实希望计划将数据取出以及将其放入和存储，因此如果您的“计划”功能包括报告，那将极大地影响数据库的设计，因此可能要为此做好计划。

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

所以总的来说，YAGNI 仍然适用。

Answer 7

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

一个好的框架应该有一些用于执行迁移的工具，这些工具可以让您轻松自动地升级和降级数据库。如果你有这个，并且对你的设计相当小心，你应该能够重构你需要的方式，而不是试图想出你需要的所有东西。

Answer 8

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

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

在实践中，如果您对转换表达式非常满意，您的 rdbms 可以处理相当多的弯曲；并且擅长它是值得的。

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