database - 什么时候可以接受平面数据库设计

Question

现在什么时候可以使用平面数据库表设计。曾经？我的意思是什么时候可以放弃关系数据库设计的智慧并恢复没有链接的平面表结构，添加额外的列来添加更多数据，什么时候我们应该创建另一个表的键来存储多行.

我正在研究一些想法，以便与产品管理团队进行讨论。当我最初问“为什么所有这些 table 本质上都是平的”这个问题时，有人告诉我“以读取为中心的数据库通过平面表结构显示出更好的性能。”

我对这种解释感到困惑，因为扁平化设计给 future 的进步带来了太多障碍。

想法？

Answer 1

“以读取为中心的数据库通过平面表结构显示出更好的性能。”该声明表示表不会/很少用于插入/更新/删除操作。在那种情况下，表必须正确索引才能获得良好的性能。由于不会有任何类型的连接，因此表会在 where 子句中使用大量过滤器，因此正确使用索引非常重要。

这种场景通常用在数据仓库中。我们在设计仓库的时候，通常会去掉主键/外键，使用业务主键。这是因为仓库中有庞大的数据库。