数据库设计：多角色多用户场景，选额外字段还是独立表？

针对你描述的「营销团队共享单个账户、按角色分配权限」的需求，我整理了一套清晰、可扩展的数据库结构设计，兼顾灵活性和业务实际需求：

一、核心表结构设计 #

这套设计通过多对多关联实现用户与账户的绑定，同时分离角色和权限模块，方便后续迭代调整：

1. 用户表（users） #

存储单个用户的基础身份信息，每个用户是独立个体，支持关联多个账户（如果业务允许跨账户操作）：

CREATE TABLE users (
    user_id INT PRIMARY KEY AUTO_INCREMENT,
    email VARCHAR(255) NOT NULL UNIQUE,
    password_hash VARCHAR(255) NOT NULL, -- 务必存储哈希值，绝对禁止明文密码
    full_name VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

2. 账户表（accounts） #

存储团队/组织级别的账户主体信息，每个账户绑定一个所有者（拥有最高权限的用户）：

CREATE TABLE accounts (
    account_id INT PRIMARY KEY AUTO_INCREMENT,
    account_name VARCHAR(100) NOT NULL UNIQUE, -- 例如「XX品牌营销中心」
    owner_user_id INT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (owner_user_id) REFERENCES users(user_id)
);

3. 账户-用户关联表（account_user_links） #

这是核心的多对多关联表，用来绑定用户与账户，同时记录该用户在账户内的角色与自定义权限：

CREATE TABLE account_user_links (
    link_id INT PRIMARY KEY AUTO_INCREMENT,
    account_id INT NOT NULL,
    user_id INT NOT NULL,
    role_id INT NOT NULL,
    permissions JSON, -- 可选：用于覆盖角色默认权限（比如给某个营销专员额外开放报表导出权限）
    is_active BOOLEAN DEFAULT TRUE, -- 快速禁用用户在该账户的权限，无需删除历史记录
    FOREIGN KEY (account_id) REFERENCES accounts(account_id),
    FOREIGN KEY (user_id) REFERENCES users(user_id),
    FOREIGN KEY (role_id) REFERENCES roles(role_id),
    UNIQUE KEY unique_account_user (account_id, user_id) -- 避免同一用户重复加入同一账户
);

4. 角色表（roles） #

预定义账户内的角色类型，比如你提到的「账户经理」「营销专员」：

CREATE TABLE roles (
    role_id INT PRIMARY KEY AUTO_INCREMENT,
    role_name VARCHAR(50) NOT NULL UNIQUE,
    default_permissions JSON -- 存储该角色的默认权限集合，例如 ["create_campaign", "view_reports", "edit_ad_groups"]
);

5. 细粒度权限扩展表（可选） #

如果需要拆分更细致的权限（比如把「营销活动管理」拆成「创建活动」「编辑活动」「删除活动」），可以补充以下两张表：

-- 权限字典表
CREATE TABLE permissions (
    permission_id INT PRIMARY KEY AUTO_INCREMENT,
    permission_code VARCHAR(50) NOT NULL UNIQUE, -- 权限唯一标识，比如 "delete_campaign"
    permission_description TEXT -- 权限说明，比如「删除已创建的营销活动」
);

-- 角色-权限关联表
CREATE TABLE role_permission_links (
    role_id INT NOT NULL,
    permission_id INT NOT NULL,
    PRIMARY KEY (role_id, permission_id),
    FOREIGN KEY (role_id) REFERENCES roles(role_id),
    FOREIGN KEY (permission_id) REFERENCES permissions(permission_id)
);

二、权限逻辑说明 #

1. 默认权限与自定义权限：角色自带预设的默认权限，若单个用户需要特殊权限，可在account_user_links的permissions字段中单独覆盖（新增或移除权限）。
2. 账户所有者特权：在业务逻辑中可以设定，账户所有者默认拥有该账户的所有权限，不受角色限制，且只有所有者能添加/删除账户内的其他用户。
3. 权限校验流程：用户登录后，先获取其关联的所有账户（若存在多个），再根据account_user_links中的角色和自定义权限，判断是否允许执行某一操作。

三、业务细节建议 #

• 用户登录时，如果关联了多个账户，可提供账户选择界面；若仅关联一个，则直接进入对应账户。
• 用is_active字段禁用用户权限比删除记录更安全，保留历史关联信息便于后续追溯或恢复权限。
• 权限校验尽量在业务层实现，数据库层面只做关联存储，避免逻辑耦合。

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