面试复盘：MySQL 中多层级部门表和成员表的设计

最近在准备数据库相关的面试题时，遇到一个很有意思的问题："如果部门有许多层级，如何设计部门表和成员表？"这个问题在实际项目中很常见，比如公司组织架构可能是多层级的：总部 > 分公司 > 部门 > 小组。设计时既要支持层级查询，又要方便维护和扩展。虽然面试还没遇到这个题，但我决定自己复盘一下，整理出清晰的思路和方案，备战未来的挑战。

问题背景

假设一个公司有复杂的部门层级，比如：

总部
- 北京分公司
  - 技术部
    - 前端组
    - 后端组
  - 销售部
- 上海分公司
  - 运营部

每个部门可能有员工，而员工只属于某个具体部门。目标是设计数据库表结构，支持：

查询某个部门的上下级关系。
查询某个部门下的所有员工。
高效维护层级（增删改部门）。

方案分析

在 MySQL 中，设计多层级结构通常有几种常见方法。我复盘时总结了以下两种最适合的方案，并结合部门和成员的需求进行设计。

方案 1：父子关系法（Adjacency List）

思路：每个部门记录它的直接父部门，用 parent_id 字段表示层级关系。

部门表设计：

sql 复制代码

CREATE TABLE departments (
    dept_id INT PRIMARY KEY AUTO_INCREMENT,  -- 部门ID
    dept_name VARCHAR(100) NOT NULL,         -- 部门名称
    parent_id INT,                           -- 父部门ID，顶级部门为 NULL
    FOREIGN KEY (parent_id) REFERENCES departments(dept_id) ON DELETE SET NULL
);

成员表设计：

sql 复制代码

CREATE TABLE employees (
    emp_id INT PRIMARY KEY AUTO_INCREMENT,   -- 员工ID
    emp_name VARCHAR(100) NOT NULL,          -- 员工姓名
    dept_id INT NOT NULL,                    -- 所属部门ID
    FOREIGN KEY (dept_id) REFERENCES departments(dept_id) ON DELETE RESTRICT
);

示例数据：

sql 复制代码

INSERT INTO departments (dept_id, dept_name, parent_id) VALUES
(1, '总部', NULL),
(2, '北京分公司', 1),
(3, '技术部', 2),
(4, '前端组', 3),
(5, '后端组', 3),
(6, '上海分公司', 1);

INSERT INTO employees (emp_name, dept_id) VALUES
('张三', 4),  -- 前端组
('李四', 5);  -- 后端组

查询示例：

查询技术部下的所有子部门：

sql 复制代码

WITH RECURSIVE dept_tree AS (
    SELECT dept_id, dept_name, parent_id
    FROM departments
    WHERE dept_id = 3  -- 技术部
    UNION ALL
    SELECT d.dept_id, d.dept_name, d.parent_id
    FROM departments d
    INNER JOIN dept_tree dt ON d.parent_id = dt.dept_id
)
SELECT * FROM dept_tree;

输出：技术部、前端组、后端组。

查询前端组的所有员工：

sql 复制代码

SELECT emp_name FROM employees WHERE dept_id = 4;

优点：
- 简单直观，容易理解和维护。
- 添加或删除部门只影响直接父子关系。
缺点：
- 查询整棵树或深层级时需要递归（CTE 或存储过程），MySQL 性能可能受限。
适用场景：层级不深、查询需求简单的场景。

方案 2：路径枚举法（Materialized Path）

思路：用一个字段记录部门的完整路径（如 1/2/3/4 表示总部 > 北京分公司 > 技术部 > 前端组）。

部门表设计：

sql 复制代码

CREATE TABLE departments (
    dept_id INT PRIMARY KEY AUTO_INCREMENT,
    dept_name VARCHAR(100) NOT NULL,
    path VARCHAR(255) NOT NULL  -- 路径，如 "1/2/3"
);

成员表设计：与方案 1 相同。

sql 复制代码

CREATE TABLE employees (
    emp_id INT PRIMARY KEY AUTO_INCREMENT,
    emp_name VARCHAR(100) NOT NULL,
    dept_id INT NOT NULL,
    FOREIGN KEY (dept_id) REFERENCES departments(dept_id) ON DELETE RESTRICT
);

示例数据：

sql 复制代码

INSERT INTO departments (dept_id, dept_name, path) VALUES
(1, '总部', '1'),
(2, '北京分公司', '1/2'),
(3, '技术部', '1/2/3'),
(4, '前端组', '1/2/3/4'),
(5, '后端组', '1/2/3/5'),
(6, '上海分公司', '1/6');

INSERT INTO employees (emp_name, dept_id) VALUES
('张三', 4),
('李四', 5);

查询示例：
- 查询技术部下的所有子部门：
  sql 复制代码
```
SELECT dept_id, dept_name
FROM departments
WHERE path LIKE '1/2/3/%' OR dept_id = 3;
```
  输出：技术部、前端组、后端组。
- 查询前端组的所有员工：与方案 1 相同。
优点：
- 查询子树或祖先节点非常高效，直接用 LIKE 匹配。
- 不需要递归，适合深层级结构。
缺点：
- 维护路径较复杂，新增或移动部门时需要更新所有子节点的 path。
- 路径长度可能受限于字段大小。
适用场景：层级较深、查询频繁但修改少的场景。

选择建议

复盘时我对比了两种方案：

父子关系法：适合中小型组织，层级不超过 5-10 层，维护简单。
路径枚举法：适合大型组织，层级复杂且查询性能要求高，但需要额外的维护逻辑（比如触发器或程序自动更新路径）。

考虑到部门和成员表的关系，employees 表只需要关联 dept_id，两种方案都兼容。如果业务需要频繁查询整棵树，我倾向于路径枚举法；如果更注重维护性，父子关系法更合适。

复盘感想

这个问题的核心是"层级结构"的建模。面试时如果被问到，我可以先抛出两种方案：

"父子关系法用 parent_id，简单但递归查询稍复杂。"
"路径枚举法用 path 字段，查询高效但维护成本高。" 然后根据面试官的倾向（性能还是维护性）展开细节，比如 SQL 示例或优缺点分析。

加分点 ：提到 MySQL 的 WITH RECURSIVE（8.0+ 支持）或路径更新的触发器实现。

总结

多层级部门表和成员表的设计，推荐以下结构：

部门表 ：用 parent_id（父子关系法）或 path（路径枚举法）表示层级。
成员表 ：通过 dept_id 关联部门，保持简单。根据业务需求选择方案，这次复盘让我对树形结构的数据库设计更有信心了！