前端扁平化数据转树形数据_带你通关全栈树型结构设计：从数据库到前端

最新推荐文章于 2024-03-10 14:12:30 发布

PixelPuzzlist

最新推荐文章于 2024-03-10 14:12:30 发布

阅读量325

点赞数

文章标签：前端扁平化数据转树形数据

本文链接：https://blog.csdn.net/weixin_30923447/article/details/112516106

版权

树状结构的业务

今天咱们要讨论的树，它不是现实结构的树，也不是数据结构要讨论的树，而是从业务视角抽象出来的树形结构。

树形结构可以用在很多的业务上，比如组织结构中的上下级关系、商品分类管理、文件系统、后台系统中的页面和组件关系等等。

下面请系好安全带，我们将从数据库设计、设计模式、前端组件三个方面来介绍关于树状结构设计的方方面面，助你通关全栈树状结构！

数据库设计

树状结构最简单最常用的方法其实是直接存储在JSON里面。现在有很多主流的NoSQL库，比如MongoDB等，而且也有很多关系型数据库也开始支持JSON存储，比如MySQL。

使用JSON的好处是，维护整棵树比较方便，直接整存整取就好了，不用去管中间是怎么修改的，怎么映射到数据库的。但缺点是不太高效，比如想要编辑某个叶子节点，查询和更新都没有纯关系型数据那么方便。所以如果你的业务足够简单，数据量也很小，可以使用JSON。否则，还是推荐使用关系型数据来实现。

那如何在关系型数据应该如何设计，才能高效地存储和操作树形结构呢？我们用下图来作为例子：

ps：这里假设有多棵树，根节点是亚洲、美洲等

我们首先想到的是用parent_id, 这个字段用来存储“父节点”，根节点的parent_id为0，这样就可以通过递归查询得到一棵树。

很明显，如果只是一个parent_id，我们如果想获得一棵树，当这棵树的深度比较深时，我们需要查询很多次数据库，效率非常低。那有没有什么办法可以一次性把整棵树都查出来呢？我们尝试加一个root_id，用来表示这棵树的根节点。

idparent_idroot_idname100亚洲200美洲311中国411日本511韩国631四川省

那么问题来了，如果是想查询某一个节点的子树，该怎么做呢？是不是觉得不太方便？下面我们推荐另外一种表示方式：full id path，每个节点记录下从根节点到自己的id路径，如下：

idfull_id_pathname1/1亚洲2/2美洲3/1/3中国4/1/4日本5/1/5韩国6/1/3/6四川省7/1/3/6/7成都市

这样如果我们想查询一棵树，只需要使用like语句前缀匹配就行了。比如想查询“四川省”下面有哪些市：

SELECT * FROM table WHERE full_id_path like "/1/3/6%";

如果是更新了一棵树中节点的关系，只需要维护好这个节点及其子节点的full_id_path字段就行了。一般来讲，这种full id path设计能够满足绝大多数树形结构的业务要求。

但如果你的id是UUID类型的，如果深度比较高，那full_id_path字段就会比较长，且并不易读。这个时候我们建议使用一个唯一的，有业务意义的code来表示路径，字段名改为叫full_path。比如要表示成都市：

'/Asian/China/SiChuan/Chengdu'

数据库的设计还是要根据业务来，没有绝对的银弹。有时候，我们会加上level字段表示每个节点在树中的层级位置，用于在应用代码层面更方便、高效地拼接树。

设计模式 - 组合模式

接下来我们介绍在代码层面，如何去优雅地使用树形结构。其实前辈们已经为我们总结出了一种非常优秀的设计模式——组合模式，又称为“部分整体模式”，专门针对树形结构。

组合模式的精髓在于，你不用把一棵树“树”的概念和一个单独的“节点”分开处理，而是都视为同一种对象来处理。下面我们依然以上面的区域关系为例，来介绍组合模式如何使用。

首先我们来看一个经典的组合模式中的三个概念：

Component：抽象接口，定义组合的外观行为；
Composite：容器对象，表示“有孩子”的节点；
Leaf：叶子节点，表示“没有孩子”的节点。

下面上Java代码实现：

/** * 组合模式抽象接口 */public interface LocationComponent {    String getPath();    void display();    void add(LocationComponent component);    void remove(LocationComponent component);    Map getChildren();}

/** * 容器对象,表示有孩子的节点 */public class LocationComposite implements LocationComponent {    private Long id;    private String name;    private String fullPath;    private Map children = new HashMap<>();    @Override    public String getPath() {        return fullPath;    }    @Override    public void display() {        System.out.println(name);    }    @Override    public void add(LocationComponent component) {        component.fullPath = this.fullPath + "/" + component.id;        children.put(component.getPath(), component);    }    @Override    public void remove(LocationComponent component) {        children.remove(component.getPath());    }    @Override    public Map getChildren() {        return children;    }}

/** * 叶子节点 */public class LocationLeaf implements LocationComponent {    private Long id;    private String name;    private String fullPath;    @Override    public String getPath() {        return fullPath;    }    @Override    public void display() {        System.out.println(name);    }    @Override    public void add(LocationComponent component) {        throw  new UnsupportedOperationException();    }    @Override    public void remove(LocationComponent component) {        throw  new UnsupportedOperationException();    }    @Override    public Map getChildren() {        throw  new UnsupportedOperationException();    }}

那么问题来了，我有必要把节点分成Leaf和Composite吗？Leaf也实现Component接口，但抛那么多UnsupportedOperationException意义何在？我为什么不用同一个对象来表示Composite和Leaf？

其实从这里我们就可以看到，经典的设计模式也不是银弹。我们学设计模式，学的是思想，而不是固定的套路，最终还是要结合业务。比如上面的代码，明显就不适合我们的“区域”业务，比如我想在高新区下面再细分“街道”，这个代码就很难扩展了。

但如果你的业务是做一个文件系统，我们可以很明显的知道，文件和文件夹的区别。文件就是一个Leaf，它必然不支持add、remove、getChildren等操作，而文件夹是必须有这些操作的，是一个Composite。这个时候就可以用上面的代码设计了。同时，上面的Map也可以换成List等其它容器类型。

所以我们要活学活用，针对我们的区域业务，可以直接用一个Component来表示：

/** * 区域接口，可扩展成无限深度 */public class AreaComponent {    private Long id;    private String name;    private String fullPath;    private Map children = new HashMap<>();    public String getPath() {        return fullPath;    }    public void display() {        System.out.println(name);    }    public void add(AreaComponent component) {        component.fullPath = this.fullPath + "/" + component.id;        children.put(component.getPath(), component);    }    public void remove(AreaComponent component) {        children.remove(component.getPath());    }    public Map getChildren() {        return children;    }}