sql - Oracle 中什么更快？树形结构的小 table vs. 巨大的平板 table

Question

我正在设计一个将使用Oracle的应用程序，并且我们有需要在数据库中映射的部门层次结构。有些东西看起来像这样(我很确定你们都知道我在说什么，但为了以防万一，我会添加 ERD 的一部分):

因此它将存储如下所示的数据:

[1 | 0]
[2 | 1]
[3 | 2]
[4 | 2]

换句话说:

Department 1
     |__Department 2
             |___Department 3
             |___Department 4

等等...

这将增加表上所需的记录数量，并且可以使用 CONNECT BY 访问数据。 命令，每个部门只有 1 条记录。我们通常采用这种树结构作为解决方案，但在这个新应用程序中，性能至关重要，所以我想知道如果我有一个像这样的扁平表格会怎样。

[1 | 0]
[2 | 1]
[3 | 1]
[3 | 2]
[4 | 1]
[4 | 2]

这使您可以拥有非常明显的关系，而无需知道给定子级的父部门即可知道其上层部门是谁。但这会增加所需的数据量，因为您需要为部门所在的每个级别提供一条记录，这意味着如果某个部门的级别比最高级别低 15 个级别，我们将需要 15 条记录。该部门相当大，因此这可能最终会成为一个巨大的表(大约 200 万条记录)。

好了，简单介绍完之后，就是这个问题了；有没有人真正尝试过这个，可以告诉我这两个选项之间的数据库更快/更便宜，巨大的平面表还是小树？

Answer 1

我肯定会选择第一个选项(分层方法)。我认为正确地对数据进行建模比仅仅使用错误的数据模型来获得性能更好。由于您在这里对层次结构进行建模，因此以这种方式将其存储在数据库中是有意义的。

如果您想要两全其美，我的建议是考虑使用 materialized view要“展平”分层数据，那么您仍然可以正确存储数据，但可以通过使用物化 View 获得性能提升(如果有)。

几乎总有一种方法可以遵循良好的数据模型，同时仍然找到获得良好性能的方法。但是一个糟糕的数据模型会让你在未来的几年里付出代价，并且以后要纠正它会付出巨大的痛苦。

但是，即使采用扁平化方法，您也必须考虑到记录数量会急剧增加，尤其是当您到达树中的叶节点时，因此如果有一个扁平的层次结构表(你的第二种方法)会提高性能，因为有更多的记录需要处理。