在关系数据库中存储分层数据的选项都有哪些？
Posted
技术标签:
【中文标题】在关系数据库中存储分层数据的选项都有哪些？【英文标题】：What are the options for storing hierarchical data in a relational database?在关系数据库中存储分层数据的选项有哪些？ 【发布时间】：2011-05-02 04:19:38 【问题描述】：良好的概述
一般来说，您是在快速读取时间（例如，嵌套集）或快速写入时间（邻接列表）之间做出决定。通常，您最终会得到最适合您需求的以下选项的组合。以下提供了一些深入阅读：
One more Nested Intervals vs. Adjacency List comparison：我发现的邻接列表、物化路径、嵌套集和嵌套区间的最佳比较。 Models for hierarchical data：幻灯片很好地解释了权衡和示例用法 Representing hierarchies in mysql: 对嵌套集的概述非常好，尤其是 Hierarchical data in RDBMSs：我见过的最全面和组织良好的一组链接，但解释的方式并不多选项
我知道的和一般特征：
-
Adjacency List:
-
Nested Set（又名Modified Preorder Tree Traversal）
O(n/2) 移动、插入、删除非常昂贵
-
Bridge Table（又名Closure Table /w triggers）
O(log n)（子树的大小）
规范化编码：适用于连接中的 RDBMS 统计信息和查询规划器
每个节点需要多行
-
Lineage Column（又名Materialized Path，路径枚举）
LEFT(lineage, #) = '/enumerated/path'）
插入、更新、删除的写入成本 O(log n)（子树的大小）
非关系型：依赖数组数据类型或序列化字符串格式
-
Nested Intervals
-
Flat Table
-
Multiple lineage columns
数据库特定说明
MySQL
Use session variables for Adjacency List甲骨文
使用CONNECT BY遍历邻接表PostgreSQL
ltree datatype 用于物化路径SQL 服务器
General summary 2008 提供了 HierarchyId 数据类型，似乎有助于使用沿袭列方法并扩展可表示的深度。【问题讨论】：
根据slideshare.net/billkarwin/sql-antipatterns-strike-back 第77 页，Closure Tables 在易用性方面优于Adjacency List、Path Enumeration 和Nested Sets（我也在猜测性能）。
我在这里错过了一个非常简单的版本：一个简单的 BLOB。如果您的层次结构只有几十个项目，则序列化的 id 树可能是最佳选择。
@Lothar：问题是一个社区 wiki，所以请随意使用。我在这方面的想法是，我只会使用那些支持某种 blob 结构的数据库，例如 XML 和稳定的查询语言，例如 XPATH。否则，除了在代码中而不是 SQL 中检索、反序列化和 munge 之外，我看不到查询的好方法。如果您确实遇到需要大量任意元素的问题，您可能最好使用像 Neo4J 这样的 Node 数据库，我已经使用并喜欢它，尽管它从未用于生产。
对于 MS SQL Server：Combination of Id-ParentId and HierarchyId Approaches to Hierarchical Data
“General Summary”的 MSDN 链接不再显示该文章。它出现在 2008 年 9 月版的 MSDN 杂志中，您可以将其下载为 CHM 文件，或通过 Web 存档查看：web.archive.org/web/20080913041559/http://msdn.microsoft.com:80/…
【参考方案1】：
这是对您问题的部分回答，但我希望仍然有用。
Microsoft SQL Server 2008 实现了两个对管理分层数据非常有用的功能：
HierarchyId 数据类型。 常用表表达式，使用with关键字。请查看 MSDN 上 Kent Tegels 的 "Model Your Data Hierarchies With SQL Server 2008" 以了解开始。另请参阅我自己的问题：Recursive same-table query in SQL Server 2008
【讨论】：
有趣，HierarchyId，不知道那个：msdn.microsoft.com/en-us/library/bb677290.aspx 确实如此。我处理大量递归分层数据，我发现公用表表达式非常有用。有关介绍，请参阅 msdn.microsoft.com/en-us/library/ms186243.aspx。【参考方案2】：我最喜欢的答案是该线程中的第一句话所建议的。使用邻接表维护层次结构，使用嵌套集查询层次结构。
到目前为止的问题是从邻接列表到嵌套集的覆盖方法非常缓慢，因为大多数人使用称为“推栈”的极端 RBAR 方法进行转换，并且被认为是通过邻接表维护的简单性和嵌套集的出色性能达到涅槃的方法是昂贵的。结果，大多数人最终不得不满足于一个或另一个，特别是如果有超过，比如说，糟糕的 100,000 个左右的节点。使用推送堆栈方法可能需要一整天的时间来转换传销者认为的百万级节点层次结构。
我想通过想出一种方法以似乎不可能的速度将邻接列表转换为嵌套集，我想给 Celko 带来一些竞争。这是我的 i5 笔记本电脑上推送堆栈方法的性能。
Duration for 1,000 Nodes = 00:00:00:870
Duration for 10,000 Nodes = 00:01:01:783 (70 times slower instead of just 10)
Duration for 100,000 Nodes = 00:49:59:730 (3,446 times slower instead of just 100)
Duration for 1,000,000 Nodes = 'Didn't even try this'
这是新方法的持续时间（括号中是推送堆栈方法）。
Duration for 1,000 Nodes = 00:00:00:053 (compared to 00:00:00:870)
Duration for 10,000 Nodes = 00:00:00:323 (compared to 00:01:01:783)
Duration for 100,000 Nodes = 00:00:03:867 (compared to 00:49:59:730)
Duration for 1,000,000 Nodes = 00:00:54:283 (compared to something like 2 days!!!)
是的，没错。 100 万个节点在不到 1 分钟的时间内完成转换，100,000 个节点在 4 秒内完成。
您可以在以下 URL 阅读有关新方法的信息并获取代码副本。 http://www.sqlservercentral.com/articles/Hierarchy/94040/
我还使用类似的方法开发了“预聚合”层次结构。传销员和制作物料清单的人会对本文特别感兴趣。 http://www.sqlservercentral.com/articles/T-SQL/94570/
如果您确实停下来看看任何一篇文章，请跳转到“加入讨论”链接，让我知道您的想法。
【讨论】：
什么是传销商？ MLM = "多层次营销"。安利、嘉康利、ACN等。【参考方案3】：如果您的数据库支持数组，您还可以将沿袭列或物化路径实现为父 ID 数组。
特别是使用 Postgres，您可以使用集合运算符来查询层次结构，并通过 GIN 索引获得出色的性能。这使得在单个查询中查找父母、孩子和深度变得非常简单。更新也很容易管理。
如果你好奇的话，我有一篇关于使用 arrays for materialized paths 的完整文章。
【讨论】：
【参考方案4】：尚未提及此设计：
Multiple lineage columns
虽然它有局限性，但如果你能承受它们，它是非常简单和非常高效的。特点：
列：每个血统级别一个，指的是直到根的所有父项，当前项级别以下的级别设置为0（或NULL） 层次结构的深度有一个固定限制 便宜的祖先，后代，等级 便宜的插入、删除、移动叶子 内部节点的昂贵插入、删除、移动下面是一个示例 - 鸟类的分类树，因此层次结构是类/顺序/科/属/物种 - 物种是最低级别，1 行 = 1 个分类单元（在叶节点的情况下对应于物种） ：
CREATE TABLE `taxons` (
`TaxonId` smallint(6) NOT NULL default '0',
`ClassId` smallint(6) default NULL,
`OrderId` smallint(6) default NULL,
`FamilyId` smallint(6) default NULL,
`GenusId` smallint(6) default NULL,
`Name` varchar(150) NOT NULL default ''
);
以及数据示例：
+---------+---------+---------+----------+---------+-------------------------------+
| TaxonId | ClassId | OrderId | FamilyId | GenusId | Name |
+---------+---------+---------+----------+---------+-------------------------------+
| 254 | 0 | 0 | 0 | 0 | Aves |
| 255 | 254 | 0 | 0 | 0 | Gaviiformes |
| 256 | 254 | 255 | 0 | 0 | Gaviidae |
| 257 | 254 | 255 | 256 | 0 | Gavia |
| 258 | 254 | 255 | 256 | 257 | Gavia stellata |
| 259 | 254 | 255 | 256 | 257 | Gavia arctica |
| 260 | 254 | 255 | 256 | 257 | Gavia immer |
| 261 | 254 | 255 | 256 | 257 | Gavia adamsii |
| 262 | 254 | 0 | 0 | 0 | Podicipediformes |
| 263 | 254 | 262 | 0 | 0 | Podicipedidae |
| 264 | 254 | 262 | 263 | 0 | Tachybaptus |
这很棒，因为这样您就可以非常轻松地完成所有需要的操作，只要内部类别不改变它们在树中的级别。
【讨论】：
【参考方案5】：这真是一道方钉圆孔题。
如果关系数据库和 SQL 是您拥有或愿意使用的唯一锤子，那么到目前为止发布的答案就足够了。但是，为什么不使用旨在处理分层数据的工具呢？ Graph database 是复杂分层数据的理想选择。
关系模型的低效率以及将图形/层次模型映射到关系模型的任何代码/查询解决方案的复杂性与图形数据库解决方案解决同样的问题。
将物料清单视为一种常见的分层数据结构。
class Component extends Vertex
long assetId;
long partNumber;
long material;
long amount;
;
class PartOf extends Edge
;
class AdjacentTo extends Edge
;
两个子组件之间的最短路径：简单的图遍历算法。可接受的路径可以根据标准进行限定。
相似度：两个程序集之间的相似度是多少？对两个子树执行遍历，计算两个子树的交集和并集。相似百分比是交集除以并集。
传递闭包：遍历子树并总结感兴趣的字段，例如“一个子组件中有多少铝？”
是的，您可以使用 SQL 和关系数据库来解决问题。但是，如果您愿意为工作使用正确的工具，还有更好的方法。
【讨论】：
如果用例演示或更好地对比了如何使用 SPARQL 而不是 RDBMS 中的 SQL 来查询图形数据库，则此答案将非常有用。 SPARQL 与 RDF 数据库相关，RDF 数据库是更大的图形数据库领域的子类。我使用 InfiniteGraph，它不是 RDF 数据库，目前不支持 SPARQL。 InfiniteGraph 支持几种不同的查询机制：(1) 用于设置视图、过滤器、路径限定符和结果处理程序的图形导航 API，(2) 复杂的图形路径模式匹配语言，以及 (3) Gremlin。【参考方案6】：邻接模型+嵌套集模型
我选择它是因为我可以轻松地向树中插入新项目（您只需要一个分支的 id 就可以向其中插入一个新项目）并且查询速度也很快。
+-------------+----------------------+--------+-----+-----+
| category_id | name | parent | lft | rgt |
+-------------+----------------------+--------+-----+-----+
| 1 | ELECTRONICS | NULL | 1 | 20 |
| 2 | TELEVISIONS | 1 | 2 | 9 |
| 3 | TUBE | 2 | 3 | 4 |
| 4 | LCD | 2 | 5 | 6 |
| 5 | PLASMA | 2 | 7 | 8 |
| 6 | PORTABLE ELECTRONICS | 1 | 10 | 19 |
| 7 | MP3 PLAYERS | 6 | 11 | 14 |
| 8 | FLASH | 7 | 12 | 13 |
| 9 | CD PLAYERS | 6 | 15 | 16 |
| 10 | 2 WAY RADios | 6 | 17 | 18 |
+-------------+----------------------+--------+-----+-----+
parent 列。
如果您需要任何父级的所有后代，您可以查询其lft 介于父级的lft 和rgt 之间的项目。
如果您需要任何节点的所有父节点直到树的根，您查询具有低于节点lft 和rgt 大于节点rgt 的项目并按@ 排序987654331@.
我需要让访问和查询树比插入更快，这就是我选择这个的原因
唯一的问题是在插入新项目时修复left 和right 列。好吧，我为它创建了一个存储过程，并在每次插入一个新项目时调用它，这在我的情况下很少见，但它真的很快。
我从 Joe Celko 的书中得到了这个想法，DBA SE 中解释了存储过程以及我是如何想到它的
https://dba.stackexchange.com/q/89051/41481
【讨论】：
+1 这是一种合法的方法。根据我自己的经验，关键是决定在发生大型更新操作时是否可以接受脏读。如果没有，这将成为问题或阻止人们直接查询表并始终通过 API - 数据库存储过程/函数或代码。 这是一个有趣的解决方案；但是，我不确定在尝试查找子列时查询父列是否真的提供了任何主要优势——这就是为什么我们首先有左列和右列。 @Thomas，children 和 descendants 之间存在差异。 left 和 right 用于查找后代。【参考方案7】：
我将 PostgreSQL 与我的层次结构的闭包表一起使用。 我有一个用于整个数据库的通用存储过程：
CREATE FUNCTION nomen_tree() RETURNS trigger
LANGUAGE plpgsql
AS $_$
DECLARE
old_parent INTEGER;
new_parent INTEGER;
id_nom INTEGER;
txt_name TEXT;
BEGIN
-- TG_ARGV[0] = name of table with entities with PARENT-CHILD relationships (TBL_ORIG)
-- TG_ARGV[1] = name of helper table with ANCESTOR, CHILD, DEPTH information (TBL_TREE)
-- TG_ARGV[2] = name of the field in TBL_ORIG which is used for the PARENT-CHILD relationship (FLD_PARENT)
IF TG_OP = 'INSERT' THEN
EXECUTE 'INSERT INTO ' || TG_ARGV[1] || ' (child_id,ancestor_id,depth)
SELECT $1.id,$1.id,0 UNION ALL
SELECT $1.id,ancestor_id,depth+1 FROM ' || TG_ARGV[1] || ' WHERE child_id=$1.' || TG_ARGV[2] USING NEW;
ELSE
-- EXECUTE does not support conditional statements inside
EXECUTE 'SELECT $1.' || TG_ARGV[2] || ',$2.' || TG_ARGV[2] INTO old_parent,new_parent USING OLD,NEW;
IF COALESCE(old_parent,0) <> COALESCE(new_parent,0) THEN
EXECUTE '
-- prevent cycles in the tree
UPDATE ' || TG_ARGV[0] || ' SET ' || TG_ARGV[2] || ' = $1.' || TG_ARGV[2]
|| ' WHERE id=$2.' || TG_ARGV[2] || ' AND EXISTS(SELECT 1 FROM '
|| TG_ARGV[1] || ' WHERE child_id=$2.' || TG_ARGV[2] || ' AND ancestor_id=$2.id);
-- first remove edges between all old parents of node and its descendants
DELETE FROM ' || TG_ARGV[1] || ' WHERE child_id IN
(SELECT child_id FROM ' || TG_ARGV[1] || ' WHERE ancestor_id = $1.id)
AND ancestor_id IN
(SELECT ancestor_id FROM ' || TG_ARGV[1] || ' WHERE child_id = $1.id AND ancestor_id <> $1.id);
-- then add edges for all new parents ...
INSERT INTO ' || TG_ARGV[1] || ' (child_id,ancestor_id,depth)
SELECT child_id,ancestor_id,d_c+d_a FROM
(SELECT child_id,depth AS d_c FROM ' || TG_ARGV[1] || ' WHERE ancestor_id=$2.id) AS child
CROSS JOIN
(SELECT ancestor_id,depth+1 AS d_a FROM ' || TG_ARGV[1] || ' WHERE child_id=$2.'
|| TG_ARGV[2] || ') AS parent;' USING OLD, NEW;
END IF;
END IF;
RETURN NULL;
END;
$_$;
然后为每个我有层次结构的表创建一个触发器
CREATE TRIGGER nomenclature_tree_tr AFTER INSERT OR UPDATE ON nomenclature FOR EACH ROW EXECUTE PROCEDURE nomen_tree('my_db.nomenclature', 'my_db.nom_helper', 'parent_id');
为了从现有层次结构中填充闭包表，我使用了这个存储过程：
CREATE FUNCTION rebuild_tree(tbl_base text, tbl_closure text, fld_parent text) RETURNS void
LANGUAGE plpgsql
AS $$
BEGIN
EXECUTE 'TRUNCATE ' || tbl_closure || ';
INSERT INTO ' || tbl_closure || ' (child_id,ancestor_id,depth)
WITH RECURSIVE tree AS
(
SELECT id AS child_id,id AS ancestor_id,0 AS depth FROM ' || tbl_base || '
UNION ALL
SELECT t.id,ancestor_id,depth+1 FROM ' || tbl_base || ' AS t
JOIN tree ON child_id = ' || fld_parent || '
)
SELECT * FROM tree;';
END;
$$;
闭包表定义为 3 列 - ANCESTOR_ID、DESCENDANT_ID、DEPTH。可以（我什至建议）存储 ANCESTOR 和 DESCENDANT 具有相同值的记录，而 DEPTH 的值为零。这将简化检索层次结构的查询。它们确实非常简单：
-- get all descendants
SELECT tbl_orig.*,depth FROM tbl_closure LEFT JOIN tbl_orig ON descendant_id = tbl_orig.id WHERE ancestor_id = XXX AND depth <> 0;
-- get only direct descendants
SELECT tbl_orig.* FROM tbl_closure LEFT JOIN tbl_orig ON descendant_id = tbl_orig.id WHERE ancestor_id = XXX AND depth = 1;
-- get all ancestors
SELECT tbl_orig.* FROM tbl_closure LEFT JOIN tbl_orig ON ancestor_id = tbl_orig.id WHERE descendant_id = XXX AND depth <> 0;
-- find the deepest level of children
SELECT MAX(depth) FROM tbl_closure WHERE ancestor_id = XXX;
【讨论】：
以上是关于在关系数据库中存储分层数据的选项都有哪些？的主要内容，如果未能解决你的问题，请参考以下文章