树形结构的数据库表Schema设计-基于左右值编码

树形结构的数据库表Schema设计

程序设计过程中，我们常常用树形结构来表征某些数据的关联关系，如企业上下级部门、栏目结构、商品分类等等，通常而言，这些树状结构需要借助于数据库完
成持久化。然而目前的各种基于关系的数据库，都是以二维表的形式记录存储数据信息，因此是不能直接将Tree存入DBMS，设计合适的Schema及其对
应的CRUD算法是实现关系型数据库中存储树形结构的关键。

理想中树形结构应该具备如下特征：数据存储冗余度小、直观性强；检索遍历过程简单高效；节点增删改查CRUD操作高效。无意中在网上搜索到一种很巧妙的
设计，原文是英文，看过后感觉有点意思，于是便整理了一下。本文将介绍两种树形结构的Schema设计方案：一种是直观而简单的设计思路，另一种是基于左
右值编码的改进方案。

一、基本数据

本文列举了一个食品族谱的例子进行讲解，通过类别、颜色和品种组织食品，树形结构图如下：

二、继承关系驱动的Schema设计

对树形结构最直观的分析莫过于节点之间的继承关系上，通过显示地描述某一节点的父节点，从而能够建立二维的关系表，则这种方案的Tree表结构通常设计为：{Node_id,Parent_id}，上述数据可以描述为如下图所示：

这种方案的优点很明显：设计和实现自然而然，非常直观和方便。缺点当然也是非常的突出：由于直接地记录了节点之间的继承关系，因此对Tree的任何
CRUD操作都将是低效的，这主要归根于频繁的“递归”操作，递归过程不断地访问数据库，每次数据库IO都会有时间开销。当然，这种方案并非没有用武之
地，在Tree规模相对较小的情况下，我们可以借助于缓存机制来做优化，将Tree的信息载入内存进行处理，避免直接对数据库IO操作的性能开销。

三、基于左右值编码的Schema设计

在基于数据库的一般应用中，查询的需求总要大于删除和修改。为了避免对于树形结构查询时的“递归”过程，基于Tree的前序遍历设计一种全新的无递归查询、无限分组的左右值编码方案，来保存该树的数据。

第一次看见这种表结构，相信大部分人都不清楚左值（Lft）和右值（Rgt）是如何计算出来的，而且这种表设计似乎并没有保存父子节点的继承关系。但当
你用手指指着表中的数字从1数到18，你应该会发现点什么吧。对，你手指移动的顺序就是对这棵树进行前序遍历的顺序，如下图所示。当我们从根节点Food
左侧开始，标记为1，并沿前序遍历的方向，依次在遍历的路径上标注数字，最后我们回到了根节点Food，并在右边写上了18。

第一次看见这种表结构，相信大部分人都不清楚左值（Lft）和右值（Rgt）是如何计算出来的，而且这种表设计似乎并没有保存父子节点的继承关系。但当
你用手指指着表中的数字从1数到18，你应该会发现点什么吧。对，你手指移动的顺序就是对这棵树进行前序遍历的顺序，如下图所示。当我们从根节点Food
左侧开始，标记为1，并沿前序遍历的方向，依次在遍历的路径上标注数字，最后我们回到了根节点Food，并在右边写上了18。

依据此设计，我们可以推断出所有左值大于2，并且右值小于11的节点都是Fruit的后续节点，整棵树的结构通过左值和右值存储了下来。然而，这还不够，我们的目的是能够对树进行CRUD操作，即需要构造出与之配套的相关算法。

四、树形结构CRUD算法

（1）获取某节点的子孙节点

只需要一条SQL语句，即可返回该节点子孙节点的前序遍历列表，以Fruit为例：SELECT* FROM Tree WHERE Lft BETWEEN 2 AND 11 ORDER BY Lft ASC。查询结果如下所示：

那么某个节点到底有多少的子孙节点呢？通过该节点的左、右值我们可以将其子孙节点圈进来，则子孙总数 = (右值 – 左值– 1) /
2，以Fruit为例，其子孙总数为：(11 –2 – 1) / 2 =
4。同时，为了更为直观地展现树形结构，我们需要知道节点在树中所处的层次，通过左、右值的SQL查询即可实现，以Fruit为
例：SELECTCOUNT(*) FROM Tree WHERE Lft <= 2 AND Rgt
>=11。为了方便描述，我们可以为Tree建立一个视图，添加一个层次数列，该列数值可以写一个自定义函数来计算，函数定义如下：

[sql] view
plaincopy

  1. CREATEFUNCTION

    int

    RETURNSint
    AS
    begin
    declareint
    set
    declareint
    declareint
    selectfromwhere
    begin
    selectfromwhere
    select(*) fromwhere Rgt >= @rgt

  2. end
    return
    end
    GO

基于层次计算函数，我们创建一个视图，添加了新的记录节点层次的数列：

[sql] view
plaincopy

  1. CREATEVIEW
    AS
    SELECTNameASFROMORDERBY
    GO

创建存储过程，用于计算给定节点的所有子孙节点及相应的层次：

[sql] view
plaincopy

  1. CREATEPROCEDURE

    int

    AS
    declareint
    declareint
    selectfromwhere
    begin
    selectfromwhere
    selectfromwhere @lft  @rgt orderbyASC
    end
    GO

现在，我们使用上面的存储过程来计算节点Fruit所有子孙节点及对应层次，查询结果如下：

从上面的实现中，我们可以看出采用左右值编码的设计方案，在进行树的查询遍历时，只需要进行2次数据库查询，消除了递归，再加上查询条件都是数字的比
较，查询的效率是极高的，随着树规模的不断扩大，基于左右值编码的设计方案将比传统的递归方案查询效率提高更多。当然，前面我们只给出了一个简单的获取节
点子孙的算法，真正地使用这棵树我们需要实现插入、删除同层平移节点等功能。

（2）获取某节点的族谱路径

假定我们要获得某节点的族谱路径，则根据左、右值分析只需要一条SQL语句即可完成，以Fruit为例：SELECT* FROM Tree
WHERE Lft < 2 AND Rgt > 11 ORDER BY Lft ASC ，相对完整的存储过程：

[sql] view
plaincopy

  1. CREATEPROCEDURE

    int

    AS
    declareint
    declareint
    selectfromwhere
    begin
    selectfromwhere
    selectfromwhere Rgt > @rgt orderbyASC
    end
    GO

（3）为某节点添加子孙节点

假定我们要在节点“Red”下添加一个新的子节点“Apple”，该树将变成如下图所示，其中红色节点为新增节点。

仔细观察图中节点左右值变化，相信大家都应该能够推断出如何写SQL脚本了吧。我们可以给出相对完整的插入子节点的存储过程：

[sql] view
plaincopy

  1. CREATEPROCEDURE

    int
    varchar

    AS
    declareint
    selectfromwhere
    begin
    SETON
    BEGIN
    selectfromwhere
    updatesetwhere
    updatesetwhere
    insertintoNamevalues
    COMMITTRANSACTION
    SETOFF
    end
    GO

（4）删除某节点

如果我们想要删除某个节点，会同时删除该节点的所有子孙节点，而这些被删除的节点的个数为：(被删除节点的右值 – 被删除节点的左值+ 1) /
2，而剩下的节点左、右值在大于被删除节点左、右值的情况下会进行调整。来看看树会发生什么变化，以Beef为例，删除效果如下图所示。

则我们可以构造出相应的存储过程：

[sql] view
plaincopy

  1. CREATEPROCEDURE

    int

    AS
    declareint
    declareint
    selectfromwhere
    begin
    SETON
    BEGIN
    selectfromwhere
    deletefromwhere Rgt <= @rgt

  2. updatesetwhere
    updatesetwhere
    COMMITTRANSACTION
    SETOFF
    end
    GO

五、总结

我们可以对这种通过左右值编码实现无限分组的树形结构Schema设计方案做一个总结：

（1）优点：在消除了递归操作的前提下实现了无限分组，而且查询条件是基于整形数字的比较，效率很高。

（2）缺点：节点的添加、删除及修改代价较大，将会涉及到表中多方面数据的改动。

当然，本文只给出了几种比较常见的CRUD算法的实现，我们同样可以自己添加诸如同层节点平移、节点下移、节点上移等操作。有兴趣的朋友可以自己动手编
码实现一下，这里不在列举了。值得注意的是，实现这些算法可能会比较麻烦，会涉及到很多条update语句的顺序执行，如果顺序调度考虑不周详，出现
Bug的话将会对整个树形结构表产生惊人的破坏。因此，在对树形结构进行大规模修改的时候，可以采用临时表做中介，以降低代码的复杂度，同时，强烈推荐在
做修改之前对表进行完整备份，以备不时之需。在以查询为主的绝大多数基于数据库的应用系统中，该方案相比传统的由父子继承关系构建的数据库Schema更
为适用。

参考文献：《Storing Hierarchical Data in
a Database Article》

转载：http://blog.csdn.net/dreajay/article/details/8894058

时间： 2024-10-13 11:21:10

树形结构的数据库表Schema设计-基于左右值编码的相关文章

树形结构的数据库表Schema设计

今天又有幸遇到一个不知道的东西,那就是树型结构在数据库表中设计的问题.由于只是阅读了人家的东西,就直接给连接吧. 第一个:http://blog.csdn.net/monkey_d_meng/article/details/6647488 第二个:http://my.oschina.net/XYleung/blog/99604 两个讲的都是一个道理,不同的人合适不同的版本吧.都给大家吧.

无限树形结构的数据库表设计

前言: 无限树形结构的数据库表设计的是否合理,直接影响到UI层是否方便根据树来查询关联的数据. 1.表字段: F_BtEd2kTypeId int Unchecked F_Name nvarchar(50) Checked F_ParentTypeId nvarchar(50) Checked F_Code nvarchar(50) Checked F_RecordStatus int Checked 2.表数据: 3.说明: 如2所示, 1)如果上表的数据关联上了一张表A,通过BtEd2kTy

树形结构的数据库的存储

程序设计过程中,我们常常用树形结构来表征某些数据的关联关系,如企业上下级部门.栏目结构.商品分类等等,通常而言,这些树状结构需要借助于数据库完成持久化.理想中树形结构应该具备如下特征:数据存储冗余度小.直观性强:检索遍历过程简单高效:节点增删改查CRUD操作高效. 列举了一个食品族谱的例子进行讲解,通过类别.颜色和品种组织食品,树形结构图如下: 1,对树形结构最直观的分析莫过于节点之间的继承关系上,通过显示地描述某一节点的父节点,从而能够建立二维的关系表,则这种方案的Tree表结构通常设计为:{

SaaS模式应用之多租户系统开发（单数据库多Schema设计）

SaaS是Software-as-a-Service(软件即服务)的简称,这边具体的解释不介绍. 多租户的系统可以应用这种模式的思想,将思想融入到系统的设计之中. 一.多租户的系统,目前在数据库存储上,一般有三种解决方案: 1.独立数据库 2.共享数据库,隔离数据架构 3.共享数据库,共享数据架构 这里我就系统的实际需求情况,选择了第二种解决方案,下面简单介绍下 二.数据库我选用的是SqlServer,因为SqlServer自带的Schema刚好符合这种需求.至于Mysql,Oracle的Sch

数据库 表关系设计参考

表关系设计 出版社表关系 # 出版社表 class Publisher(models.Model): name = models.CharField(max_length=32) addr = models.CharField(max_length=128) phone = models.IntegerField() def __str__(self): return self.name # 作者表 class Author(models.Model): name = models.CharFi

MySQL数据库优化技术之数据库表的设计

三范式介绍表的范式:只有符合的第一范式,才能满足第二范式,进一步才能满足第三范式. 1. 第一范式:表的列具有原子性,不可再分解.只要是关系型数据库都自动满足第一范式.数据库的分类:关系型数据库:MySQL/ORACLE/Sql Server/DB2等非关系型数据库:特点是面向对象或者集合nosql数据库:MongoDB(特点是面向文档) 2. 第二范式:表中的记录是唯一的,就满足第二范式.通常我们设计一个主键来实现.主键一般不含业务逻辑,一般是自增的: 3. 第三范式:表中不要有冗余数据,即如

数据库表的设计 注意点

注意点: 如果是代码表基本不会变化的我们可以只设计  dm字段而不加pkid字段  代码表还会不断变化的话我们再加一个pkid自增长,如果涉及到外键我们要引用的是dm而不是pkid,因为这样我在导入数据的时候可以避免数据对不上.  业务表的话我们还是也加一个dm(可以guid)字段好了,Pkid自增长或者我们只要一个Id(guid)这样都是防止自增长的特性导致导入数据混乱,那么我们guid还是在前台生成好再插进去,不然同样会导致和自增长一样的导入数据混乱.

支付业务的数据库表的设计

一.数据表 数据库中的数据表是整个核心逻辑的载体说在,所有的记账逻辑.以及与支付前台交互的数据都是在这里 进行记录.现就主要的表进行简要说明.不同的第三方支付其数据表名称肯定也不同,这里的表名称仅作参考 gTransLog表: 支付网关交易流水表,所有通过网关的交易全部都会在此表中写入数据. tAccounts表: 用户的账户数据记录表,在第三方系统中其记录着用户的账上资金. tAccountLog表: 用于记录账户的自己流水情况,所有对tAccounts表的资金变动都会在流水表中进行记录 tB

数据库表的设计

首先建立sell.sql文件,在里面输入: create table 'product_info' ( 'product_id' varchar(32) not null, #因为是企业级项目,防止不够用,所以用varchar字符类型. 'product_name' varchar(64) not null comment '商品名称', 'product_price' decimal(8,2) not null comment '单价', 'product_stock' int not nul