树形数据库有哪些

树形数据库介绍与特征：

关系数据库中BOM结构是树状的，但是速度不怎么样。

理想中树形结构应该具备如下特征：

数据存储冗余度小、直观性强；

检索遍历过程简单高效；

节点增删改查CRUD *** 作高效。

所谓树形结构就是指，存在“一对多”的数据结构，举一个例子就是：

一棵树，只有一个树干，但是有多个树枝、和许多的树叶。树型结构：网站下面有许多目录或栏目，目录或栏目中再放属于该目录或栏目的网页。结构清楚，URL语义明确，识别度高，搜索引擎处理内部链接的权值传递会比较容易，后期管理比较容易。但是过深的树层次将导致收录速度下降，而且过密的网结构也会导致网站结构混乱，链接复杂，容易导致蜘蛛效率的下降，所以，做好树型结构的栏目组织和链接优化至关重要。这种结构适合内容类别多、内容量大的网站。

树形结构的网站：象什么人事部门的网站，财务网站等等很多。

那么采用树形结构有怎样的好处呢？

1、易扩展

我们的网站永远不是完美，所以总会遇到多多少少改动，那么如果采用了树形结构，就会非常容易扩展，你只需要多开一个栏目，就可以完成一个新内容的添加。

2、分类性强

树形结构是一种非常整洁的结构方式，它不像扁平化结构那样，容易把根目录搞混，可以按照栏目分类方式，建立独立的文件夹，并存在相同分类的内容，这样会帮助搜索引擎更便捷找到相关文章。

3、管理成本低

因为采用树形结构后，你的内容以分类方式保存，那么在实施某一栏目改版、升级，可以做到非常的精准，避免遗漏和误删的麻烦。

本文主要是分享了，什么是树形结构?以及采用树形结构的好处，如果你对于树形结构有疑问，欢迎在评论中留言，我会及时回复的。

本文来自

文中使用公司部门结构树作为栗子，要在mysql中存储这个公司部门结构树

邻接表想必大家都不陌生吧，用邻接表的关键是，在每个节点存储他的父节点的id。

在每一个部门信息中都存储了他的父节点id，parent_id字段

导入数据的过程就不说了，直接来看下数据吧：

这里使用常用的几种查询方式来看下这种方案的查询

可以通过parent_id做查询条件，可以快速查询到一个部门的直属下级部门

通过部门信息中的parent_id去查相应的父节点信息就可以快速实现

这种数据存储结构下，更新数据是比较方便快捷的，添加数据时直接找准父节点的id，组织部门变更时，也直接变更父id就好了，删除时候，看自己业务是否需要删除子节点这几种情况，

路径标的要点，就是每个节点存储根节点到该节点的路径，其实我觉得和别的几种方案可以共用

在每一个部门信息中都存储了他完整的路径，path字段

导入数据的过程就不说了，直接来看下数据吧：

使用路径表，通过path这个字段查询起来是比较困难的，一般都需要使用like，CONCAT函数、REPLACE函数等做字符串的处理逻辑，查询起来比较复杂，这里不做展示了，线上服务不建议使用这种方式，查询效率低会影响到服务性能，一般建议和邻接表方式统一使用，同时添加parent_id和path字段，parent_id用来查询，path用来查看节点完整的路径

这种数据存储结构下，更新数据是比较方便快捷的，添加数据时直接找准路径就好，组织部门变更时，也直接找准路径就好，删除时候，看自己业务是否需要删除子节点这几种情况，

Closure Table，百度直译过来叫闭合表，大多数人叫做闭包表，这种方案的要点是存储公司部门信息主表中，不存储节点关系的数据，使用另一张关系表来存储节点之间的关系，其中包含了任何两个有关系（上下级）节点的关联信息

公司部门信息主表，只需要存储部门的本身信息

主要包括三个字段

要点就是关系表的一条记录是一个上级节点、下级节点、与他们之间的路径距离。拿部门结构图来举例子

总公司-企划部的关系数据是：

总公司-大区A的关系数据是：

关系表中存储所有的节点路径信息，还用distance表示路径的距离，需要把树形结构中每两个节点之间的路径信息都维护进来。

数据存储的过程就拿导入总公司-门店A的过程做个示例。主表的数据存储就不说，说下关系中，存储部门结构的路径信息，总公司-门店A总共包含以下几条路径：

看到了么，是存储了所有总公司-门店A之间的路径信息

这里使用常用的几种查询方式来看下这种方案的查询

这种数据存储结构下，更新数据比较麻烦，因为他存储了两节点直接所有路径信息（包括中间节点的）

---