创建分层定义的数据集的展平表/视图

Question

我有一个包含分层数据的表。目前在这个层次中有〜8个层次。

我真的很喜欢的方式，数据的结构，但性能是令人沮丧的，当我需要知道，如果在8级的纪录是在级别1

记录的一个孩子，我有PL/SQL存储函数为我做这些查询，每个都有一个select * from tbl start with ... connect by...声明。当我查询一些记录时，这很好，但我现在处于一种情况，我需要一次查询〜10k条记录，并且每个记录都运行此函数。这需要2-3分钟，我需要它在几秒钟内运行。

根据我对当前数据的了解，我可以摆脱查找功能，只是做childrecord.key || '%' LIKE parentrecord.key，但这是一个非常肮脏的黑客攻击，并不总是工作。

所以现在我想这对于这个分层定义的表我需要有一个单独的父子表，它将包含每一个关系...对于层次从1-8级将会有8！记录，将1与2，1与3，...，1与8和2与3，2与4，...，2与8相关联。等等。

我的想法是，我需要一个插入触发器，它将基本上运行connect by查询，对于层次结构中的每个匹配项，它都会在查找表中插入一条记录。而为了处理旧数据，我只需将级联删除的外键设置到主表。

有没有比这更好的选择？我是否错过了另一种可以更快地确定这些遥远的祖先/后代关系的方式？

编辑：这似乎正是我在想：http://evolt.org/working_with_hierarchical_data_in_sql_using_ancestor_tables

Answer 1

所以，你想要的是物化的传递闭。也就是说，考虑到该应用程序表...

ID | PARENT_ID 
------+---------- 
    1 | 
    2 |   1 
    3 |   2 
    4 |   2 
    5 |   4 

...图形表是这样的：

PARENT_ID | CHILD_ID 
-----------+---------- 
     1 |  2 
     1 |  3 
     1 |  4 
     1 |  5 
     2 |  3 
     2 |  4 
     2 |  5 
     4 |  5 

很可能维持这样Oracle中的表，虽然你会需要为它推出自己的框架。问题是这是否值得开销。如果源表非常不稳定，那么保持图表数据更新可能会花费更多的周期，这比您在查询中保存的周期还要多。只有你知道你的数据的个人资料。

我不认为你可以用CONNECT BY查询和级联外键维护这样一个图表。太多的间接活动，太难以正确对待。此外，物化视图已不存在，因为我们无法编写SQL查询，该查询在删除ID=4的源记录时将删除1->5记录。

所以我建议你阅读Dong，Libkin，Su和Wong的文章Maintaining Transitive Closure of Graphs in SQL。这包含了许多理论和一些粗糙的（Oracle）SQL，但它会为您建立维护图表所需的PL/SQL奠定基础。

---

“你能在有关部分展开 太困难 CONNECT BY /级联FKS维护？如果我控制 访问表和所有 插入/更新/删除发生通过 存储过程，有哪些 场景在那里会出现这种情况， 会崩溃？“

考虑记录1->5这是1->2->4->5的短路。现在如果像我之前说过的那样删除ID=4的源记录，会发生什么情况？级联外键可以删除2->4和4->5的条目。但是这在图表中留下了1->5（实际上2->5），尽管它们不再代表图中的有效边缘。

什么可能工作（我想，我没有这样做）将是在源表中使用一个额外的合成密钥，就像这样。现在

ID | PARENT_ID | NEW_KEY 
------+-----------+--------- 
    1 |   | AAA 
    2 |   1 | BBB 
    3 |   2 | CCC 
    4 |   2 | DDD 
    5 |   4 | EEE 

图形表是这样的：

PARENT_ID | CHILD_ID | NEW_KEY 
-----------+----------+--------- 
     1 |  2 | BBB 
     1 |  3 | CCC 
     1 |  4 | DDD 
     1 |  5 | DDD 
     2 |  3 | CCC 
     2 |  4 | DDD 
     2 |  5 | DDD 
     4 |  5 | DDD 

使图形表有一个外键引用中产生的，而不是链接到ID源表的关系。然后删除ID=4的记录将级联删除图表中的所有记录，其中NEW_KEY=DDD。

如果任何给定的ID只能有零个或一个父ID，这将工作。但它不会工作，如果它是允许这种情况发生：

ID | PARENT_ID 
------+---------- 
    5 |   2 
    5 |   4 

换句话说边缘1->5既代表1->2->4->5和1->2->5。那么，可能会发挥什么取决于数据的复杂性。