微服务后端数据库设计：是否需拆分部门与职位表？

结论 #

一定要新增独立的职位表，别把职位当员工表的字段存，这完全适配你提到的每日按职位统计、部门-职位关联的业务需求，还能避免后续一堆麻烦。

为什么要这么做？ #

• 管得住部门和职位的对应关系：你公司里每个部门有固定的职位（比如开发部才有Backend），用独立职位表的话，可以给职位表加个department_id外键绑定部门，从数据库层面就杜绝了“运维部出个Backend”这种不符合业务逻辑的数据。以后部门要加新职位（比如开发部新增Mobile岗），直接在职位表插一行就行，不用改其他表结构。
• 统计查询更高效、更靠谱：你需要每天按职位算分配人数、查空闲人员。如果职位是员工表的字符串字段，统计时要对字符串分组，不仅慢，还容易因为拼写错误（比如把Backend写成BackEnd）导致统计数不准。用独立职位表的话，靠position_id关联查询，能加索引提速，统计逻辑也更清晰。
• 留足扩展空间：以后要是想给职位加属性（比如职位等级、职责说明），直接在职位表加字段就行，不用动员工表。员工调岗的话，改一下员工表的position_id就搞定，比改字符串字段更不容易出错。

简单的表结构示例 #

-- 部门表
CREATE TABLE departments (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50) UNIQUE NOT NULL -- 开发、产品、数据科学、运维
);

-- 职位表
CREATE TABLE positions (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50) NOT NULL, -- Backend、Frontend、SRE等
    department_id INT NOT NULL,
    FOREIGN KEY (department_id) REFERENCES departments(id),
    UNIQUE KEY (department_id, name) -- 同一部门下职位名称不能重复
);

-- 员工表
CREATE TABLE employees (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(100) NOT NULL,
    position_id INT NOT NULL,
    FOREIGN KEY (position_id) REFERENCES positions(id),
    -- 其他字段：入职时间、联系方式等
);

举个查询的例子 #

比如查当天空闲的Backend开发：

SELECT e.id, e.name
FROM employees e
JOIN positions p ON e.position_id = p.id
JOIN departments d ON p.department_id = d.id
WHERE d.name = '开发' 
  AND p.name = 'Backend'
  AND e.id NOT IN (
      SELECT employee_id 
      FROM project_allocations 
      WHERE allocation_date = CURDATE()
  );

内容的提问来源于stack exchange，提问作者Diegol