电商平台商户员工数据库结构选型及权限设计咨询

阿华AIGC实验室

2026-5-8

电商商户员工体系与权限设计建议

先直接给你结论：方案二更适合长期维护和权限扩展，咱们一步步拆解原因和权限设计的核心思路，帮你理清困惑。

一、两种数据库方案的优劣对比

方案一：在`merchants`表新增`merchant_id`字段

这种方案看似省事儿，但其实埋下了不少隐患：

身份边界模糊：商户是独立的经营主体，员工是商户的附属角色，把两者混在同一张表，后期很难快速区分“商户自身账号”和“员工账号”，数据统计、排查问题都会变麻烦。
权限扩展受限：如果后续要给员工分不同权限（比如财务、运营、客服），只能在merchants表不断加字段，表结构会越来越臃肿，而且商户本身的权限和员工权限没法有效隔离。
扩展性差：万一以后你的电商平台要支持商户层级（比如连锁商户），这个merchant_id字段就会和“上级商户关联”的需求冲突，到时候改表成本极高。

当然它也有优点：初期开发快，不用新建表，但这些优势只存在于项目最早期，长期来看得不偿失。

方案二：新建独立`employees`表

这是更合理的架构选择：

身份清晰：商户和员工的数据完全分离，一眼就能区分主体和附属角色，后续做数据统计（比如某商户的员工数量）、账号管理（员工离职删除）都非常方便。
权限扩展灵活：员工表可以单独加权限相关字段，或者关联专门的权限表，完全不会影响商户表的结构。
留足扩展空间：以后如果要支持员工跨商户协作（虽然现在可能不需要）、员工转岗等需求，调整起来成本极低。

唯一的小缺点是初期多建一张表，开发量稍微大一点，但长远来看绝对值得。

二、核心：员工权限分配的设计思路

权限设计的核心是**“清晰划分权限维度，兼顾灵活性和易用性”**，给你两种可行的模式：

1. 角色组+细粒度权限（推荐，适合中大型商户）

这是行业通用的成熟方案，适合后续有规模化扩展需求的场景：

第一步：先梳理所有可能的权限项，比如：
- 商品管理：goods_add（新增商品）、goods_edit（编辑商品）、goods_off（商品下架）
- 订单管理：order_view（查看订单）、order_refund（处理退款）、order_export（导出订单）
- 店铺设置：shop_edit（修改店铺信息）、freight_set（设置运费模板）
第二步：定义常用角色组，比如「运营管理员」「客服专员」「财务专员」「普通员工」，每个角色组对应一批权限。
第三步：用三张关联表来实现权限绑定：
- permission表：存储所有细粒度权限项
- role表：存储角色组信息
- role_permission表：绑定角色和对应的权限
- employee_role表：给每个员工分配角色组

示例表结构（SQL）：

-- 权限表
CREATE TABLE permission (
  id INT PRIMARY KEY AUTO_INCREMENT,
  permission_code VARCHAR(50) NOT NULL UNIQUE, -- 权限唯一标识
  permission_name VARCHAR(100) NOT NULL -- 权限名称（用于后台展示）
);

-- 角色表
CREATE TABLE role (
  id INT PRIMARY KEY AUTO_INCREMENT,
  role_name VARCHAR(50) NOT NULL UNIQUE, -- 角色名称
  role_desc TEXT -- 角色描述（说明该角色的职责）
);

-- 角色-权限关联表
CREATE TABLE role_permission (
  role_id INT,
  permission_id INT,
  PRIMARY KEY (role_id, permission_id),
  FOREIGN KEY (role_id) REFERENCES role(id),
  FOREIGN KEY (permission_id) REFERENCES permission(id)
);

-- 员工-角色关联表
CREATE TABLE employee_role (
  employee_id INT,
  role_id INT,
  PRIMARY KEY (employee_id, role_id),
  FOREIGN KEY (employee_id) REFERENCES employees(id),
  FOREIGN KEY (role_id) REFERENCES role(id)
);

这种模式的好处是：不用给每个员工单独配置权限，批量管理效率高；后续新增权限或者调整角色权限，只需要修改关联表，不会影响员工数据。

2. 单员工直接绑定权限（适合小型商户）

如果你的项目初期商户规模都很小，每个商户的员工数量不多（比如3-5人），可以先采用简化方案：
在employees表中新增一个permissions字段，用JSON格式存储该员工的权限列表，比如["goods_add", "order_view"]。

这种方案的优点是开发快、成本低，但缺点也很明显：权限管理不够灵活，后期员工多了之后修改权限会很麻烦，而且没法批量调整权限。如果用这种方案，建议预留好后续升级到“角色组权限”的空间。

3. 权限校验与特殊场景处理

权限校验逻辑：后端每个需要权限的接口，都要先获取当前员工的权限列表，判断是否拥有对应的权限标识，没有就返回无权限错误。可以封装一个权限校验中间件，减少重复代码。
商户超级权限：商户自身的账号默认拥有所有权限，不需要参与权限分配，要和员工权限做严格区分。
敏感权限二次验证：比如提现、修改店铺核心信息这类高风险操作，可以增加短信/邮箱验证，或者设置为需要商户审核后才能执行。