带你通关全栈树型结构设计:从数据库到前端

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

树状结构的业务


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

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

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


数据库设计


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

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

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

区域关系

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

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

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

id parent_id root_id name
1 0 0 亚洲
2 0 0 美洲
3 1 1 中国
4 1 1 日本
5 1 1 韩国
6 3 1 四川省

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

id full_id_path name
1 /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<String, LocationComponent> getChildren();
}
/**
 * 容器对象,表示有孩子的节点
 */
public class LocationComposite implements LocationComponent {
    private Long id;
    private String name;
    private String fullPath;
    private Map<String, LocationComponent> 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<String, LocationComponent> 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<String, LocationComponent> 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<String, AreaComponent> 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<String, AreaComponent> getChildren() {
        return children;
    }
}


前端设计

作为一个有志向的全栈工程师,当然不能只满足于数据库和后端层面。前端组件代码也要自己上手~

相信现在的前端小伙伴们都应该熟悉一种或多种令人闻风丧胆的“三大”前端主流框架。现在的前端框架都推荐“组件化”开发,把页面分成一个一个小的组件。很明显,组件层层嵌套,其实本质上也是一个树的形式,最终也会渲染出一个DOM树对象。

组件树

我们以Vue为例,对于上文提到的区域划分业务,如果后端返回的是一条条带有full_path的扁平数据,前端应该如何优雅地构建基于业务的树形结构呢?答案就是使用递归组件

递归组件,简单来说就是在组件中内使用组件本身, 对于Vue来说,其核心就在于使用name字段。效果大概是这样:

请忽略我的审美

还是按照惯例,上代码。先来一个表示“区域”的组件:

<template>
  <div class="node" :style="{paddingLeft: self.level * 20 + 'px'}">
    <p>{{self.name}}</p>
    <div v-for="child in children" :key="child.id">
      <Area v-if="`children.length != 0`" :self="child" :all="all"/>
    </div>
  </div>
</template>
<script>
export default {
  name: 'Area',
  props: {
    self: Object,
    all: Array
  },
  computed: {
    children() {
      // 根据full_path和level,过滤出子组件
   return this.all.filter(item => item.full_path.startsWith(this.self.full_path) && item.level == this.self.level + 1);
    }
  }
}
</script>

入口:

<template>
  <div id="app">
    <Area :self="all[0]" :all="all" />
  </div>
</template>
<script>
import Area from './components/Area.vue'
export default {
  name: 'App',
  components: {
    Area
  },
  data() {
    return {
      // 所有数据
      all: [
        { id: 1, level: 1, full_path: '/1', name: '亚洲' },
        { id: 2, level: 1, full_path: '/2', name: '美洲' },
        { id: 3, level: 2, full_path: '/1/3', name: '中国' },
        { id: 4, level: 2, full_path: '/1/4', name: '日本' },
        { id: 5, level: 3, full_path: '/1/3/5', name: '四川省' },
        { id: 6, level: 3, full_path: '/1/3/6', name: '浙江省' },
        { id: 7, level: 4, full_path: '/1/3/5/7', name: '成都市' }
      ]
    }
  }
}
</script>

当然了,这只是其中一种写法,你也可以在外面组装好一个带children的对象传进去。


思考:计算和组装放在前端还是后端?

又到了我们一天一度的前后端撕逼环节。作为一个假装是全栈的后端同学来说,笔者认为针对这个问题,我有必要说一句公道话:在前端组装比较好。

众所周知,在当今前端越来越繁荣的大环境下,前端承担着越来越重要的角色,有很多数据的计算也会放在前端。针对于这种树状结构的拼装来说,放在前后端其实都可以的。但是放在前端有一个好处,那就是可以将计算消耗的时间和资源从服务端转移到客户端

现在的后端架构也越来越倾向于读写分离,所以在读的时候,多半不会进行太多的操作,不需要组装整棵树。这种情况下,建议直接把数据返回前端,由前端来组装成整棵树。

当然,这只是一个建议,具体在什么时机组装,还是由业务规则以及团队商量决定~

好了,以上就是从数据库到前端的树形结构实现,有任何问题欢迎留言讨论~

目录
相关文章
|
22天前
|
Cloud Native 前端开发 JavaScript
前端开发者必看:不懂云原生你就OUT了!揭秘如何用云原生技术提升项目部署与全栈能力
【10月更文挑战第23天】随着云计算的发展,云原生逐渐成为技术热点。前端开发者了解云原生有助于提升部署与运维效率、实现微服务化、掌握全栈开发能力和利用丰富技术生态。本文通过示例代码介绍云原生在前端项目中的应用,帮助开发者更好地理解其重要性。
54 0
|
26天前
|
JavaScript 前端开发 Docker
前端全栈之路Deno篇(二):几行代码打包后接近100M?别慌,带你掌握Deno2.0的安装到项目构建全流程、剖析构建物并了解其好处
在使用 Deno 构建项目时,生成的可执行文件体积较大,通常接近 100 MB,而 Node.js 构建的项目体积则要小得多。这是由于 Deno 包含了完整的 V8 引擎和运行时,使其能够在目标设备上独立运行,无需额外安装依赖。尽管体积较大,但 Deno 提供了更好的安全性和部署便利性。通过裁剪功能、使用压缩工具等方法,可以优化可执行文件的体积。
104 3
前端全栈之路Deno篇(二):几行代码打包后接近100M?别慌,带你掌握Deno2.0的安装到项目构建全流程、剖析构建物并了解其好处
|
25天前
|
JavaScript 前端开发 测试技术
前端全栈之路Deno篇(五):如何快速创建 WebSocket 服务端应用 + 客户端应用 - 可能是2025最佳的Websocket全栈实时应用框架
本文介绍了如何使用Deno 2.0快速构建WebSocket全栈应用,包括服务端和客户端的创建。通过一个简单的代码示例,展示了Deno在WebSocket实现中的便捷与强大,无需额外依赖,即可轻松搭建具备基本功能的WebSocket应用。Deno 2.0被认为是最佳的WebSocket全栈应用JS运行时,适合全栈开发者学习和使用。
|
22天前
|
缓存 前端开发 JavaScript
"面试通关秘籍:深度解析浏览器面试必考问题,从重绘回流到事件委托,让你一举拿下前端 Offer!"
【10月更文挑战第23天】在前端开发面试中,浏览器相关知识是必考内容。本文总结了四个常见问题:浏览器渲染机制、重绘与回流、性能优化及事件委托。通过具体示例和对比分析,帮助求职者更好地理解和准备面试。掌握这些知识点,有助于提升面试表现和实际工作能力。
57 1
|
26天前
|
存储 前端开发 JavaScript
前端的全栈之路Meteor篇(四):RPC方法注册及调用-更轻量的服务接口提供方式
RPC机制通过前后端的`callAsync`方法实现了高效的数据交互。后端通过`Meteor.methods()`注册方法,支持异步操作;前端使用`callAsync`调用后端方法,代码更简洁、易读。本文详细介绍了Methods注册机制、异步支持及最佳实践。
|
26天前
|
前端开发 JavaScript 中间件
前端全栈之路Deno篇(四):Deno2.0如何快速创建http一个 restfulapi/静态文件托管应用及oak框架介绍
Deno 是由 Node.js 创始人 Ryan Dahl 开发的新一代 JavaScript 和 TypeScript 运行时,旨在解决 Node.js 的设计缺陷,具备更强的安全性和内置的 TypeScript 支持。本文介绍了如何使用 Deno 内置的 `Deno.serve` 快速创建 HTTP 服务,并详细讲解了 Oak 框架的安装和使用方法,包括中间件、路由和静态文件服务等功能。Deno 和 Oak 的结合使得创建 RESTful API 变得高效且简便,非常适合快速开发和部署现代 Web 应用程序。
|
26天前
|
JSON 分布式计算 前端开发
前端的全栈之路Meteor篇(七):轻量的NoSql分布式数据协议同步协议DDP深度剖析
本文深入探讨了DDP(Distributed Data Protocol)协议,这是一种在Meteor框架中广泛使用的发布/订阅协议,支持实时数据同步。文章详细介绍了DDP的主要特点、消息类型、协议流程及其在Meteor中的应用,包括实时数据同步、用户界面响应、分布式计算、多客户端协作和离线支持等。通过学习DDP,开发者可以构建响应迅速、适应性强的现代Web应用。
|
26天前
|
JavaScript 前端开发 Serverless
前端全栈之路Deno篇:Deno2.0与Bun对比,谁更胜一筹?可能Deno目前更适合serverless业务
在前端全栈开发中,Deno 2.0 和 Bun 作为新兴的 JavaScript 运行时,各自展现了不同的优势。Deno 2.0 重视安全性和多平台兼容性,尤其是对 Windows 的良好支持和原生 TypeScript 支持;而 Bun 则以卓越的性能和简便的开发体验著称,适合快速迭代的小型项目。两者在不同场景下各具特色,Deno 更适合企业级应用和serverless,Bun 则适用于追求速度的项目。
112 1
|
26天前
|
JSON 前端开发 数据格式
前端的全栈之路Meteor篇(五):自定义对象序列化的EJSON介绍 - 跨设备的对象传输
EJSON是Meteor框架中扩展了标准JSON的库,支持更多数据类型如`Date`、`Binary`等。它提供了序列化和反序列化功能,使客户端和服务器之间的复杂数据传输更加便捷高效。EJSON还支持自定义对象的定义和传输,通过`EJSON.addType`注册自定义类型,确保数据在两端无缝传递。
|
26天前
|
前端开发 安全 API
前端全栈之路Deno篇(三):一次性搞懂和学会用Deno 2.0 的权限系统详解和多种权限配置权限声明方式
本文深入解析了 Deno 2.0 的权限系统,涵盖主包和第三方包的权限控制机制,探讨了通过命令行参数、权限 API 和配置文件等多种权限授予方式,并提供了代码示例和运行指导,帮助开发者有效管理权限,提升应用安全性。