甲骨文哪个更快？与树结构的小桌与巨大的平的桌

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个记录.该部门相当大,所以这可能最终成为一个巨大的表(约200万条记录).

好的,所以在简介之后,这就是问题所在; 有人真的试过这个可以告诉我这两个选项之间的DB更快/更便宜的东西,巨大的平台还是小树？

Answer 1

我肯定会选择第一种选择(分层方法).我认为正确建模数据比仅使用不良数据模型获得性能更好.由于您在此处对层次结构建模,因此将其存储在DB中是有意义的.

如果你想要两全其美,我的建议是看看使用物化视图来"压平"分层数据,然后你仍然正确地存储数据,但是通过使用它可以获得性能提升(如果有的话)物化观点.

几乎总有一种方法可以遵循良好的数据模型,并且仍然可以找到获得良好性能的方法.但是糟糕的数据模型将在未来几年内耗费你的成本,以后需要付出巨大的努力.

但是,即使使用扁平化方法,您也必须考虑到显着增加记录数量,尤其是当您到达树中的叶节点时,如果有一个平面层次表(第二种方法),我会感到惊讶)因为还有更多的记录要处理,所以会提高性能.