SQL表待审核用户信息存储位置及JSON列存储可行性咨询

首先直接回应你的问题：将待审核信息以JSON格式存在Infos表的某列中是可行的，但不算最优方案，下面具体分析并给出更合适的替代方案：

一、JSON列方案的优劣势 #

优点 #

• 实现成本极低：不需要新增表，只需要给Infos表加一个类似pending_changes的JSON类型字段，就能快速存放用户提交的修改内容。
• 适配灵活：如果Infos表字段偶尔变动，JSON列不需要跟着修改结构，短期适配性强。

缺点 #

• 缺乏数据约束：数据库无法校验JSON内字段的类型、格式、非空规则，所有合法性校验都要靠业务代码实现，容易出现脏数据。
• 查询与维护困难：想要单独筛选“修改了手机号的待审核请求”这类需求，SQL会非常繁琐，且JSON字段无法利用索引，数据量上去后性能会很差。
• 数据一致性风险：长期迭代中，Infos表的字段可能新增或修改，JSON列里的字段结构很容易和原表脱节，导致审核通过后更新时出现字段不匹配的问题。

二、更推荐的方案：新增独立审核表 #

针对你的场景（Infos表主键被多表大量引用，不能随意修改原表数据），最稳妥的方式是创建一张独立的审核暂存表，比如命名为Infos_Audit。

表结构参考 #

CREATE TABLE Infos_Audit (
    audit_id INT AUTO_INCREMENT PRIMARY KEY,
    user_id INT NOT NULL, -- 关联Infos表的主键
    -- 以下复制Infos表的核心业务字段，比如：
    username VARCHAR(50),
    email VARCHAR(100),
    phone VARCHAR(20),
    address TEXT,
    -- 审核相关字段
    audit_status ENUM('pending', 'approved', 'rejected') DEFAULT 'pending',
    submit_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    reviewer_id INT NULL,
    review_time DATETIME NULL,
    FOREIGN KEY (user_id) REFERENCES Infos(user_id)
);

这个方案的优势 #

1. 数据合法性保障：完全复用Infos表的字段约束，待审核数据的格式、类型都能被数据库校验，避免脏数据。
2. 查询与维护高效：可以轻松通过SQL筛选不同状态、不同修改字段的审核请求，比如SELECT * FROM Infos_Audit WHERE audit_status = 'pending' AND email IS NOT NULL，还能给常用字段加索引提升性能。
3. 审核逻辑清晰：审核通过时，直接用Infos_Audit里的对应数据更新Infos表即可；审核不通过时，直接标记状态或删除这条记录，不会影响原表数据。
4. 完整的审核日志：留存了所有修改请求的提交时间、审核人、审核时间等信息，方便后续追溯和合规检查。

三、折中方案：键值对式审核表 #

如果Infos表字段极多，且用户每次仅修改少数字段，不想维护两张结构几乎一致的表，可以采用键值对形式的暂存表，比如Infos_Audit_Changes：

CREATE TABLE Infos_Audit_Changes (
    change_id INT AUTO_INCREMENT PRIMARY KEY,
    user_id INT NOT NULL,
    field_name VARCHAR(50) NOT NULL, -- 被修改的字段名（如'email'）
    old_value TEXT, -- 原字段值
    new_value TEXT, -- 修改后的值
    audit_status ENUM('pending', 'approved', 'rejected') DEFAULT 'pending',
    submit_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    reviewer_id INT NULL,
    review_time DATETIME NULL,
    FOREIGN KEY (user_id) REFERENCES Infos(user_id)
);

这种方案节省存储空间，但审核时需要拼接多个字段才能查看完整的用户修改后状态，适合修改频率低、单请求修改字段少的场景。

总结 #

如果你的业务场景简单、字段少且长期不会有大变动，JSON列方案可以临时用；但从长期维护、性能和数据一致性角度看，独立审核表是更符合关系型数据库设计规范的方案，也更适配你的Infos表被多表引用的场景。

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