SQL多对多关系下用户旅程依赖的规范化表设计咨询

你判断的多对多关系是准确的：单个旅程可以有多个前置依赖，单个旅程节点也可以作为多个其他旅程的前置项。你最初的设计核心问题是没有拆分实体和关系、缺失主键约束，存在数据冗余和一致性风险，不符合数据库设计范式要求。

整体采用「主表存实体+关联表存关系」的经典多对多设计结构，完全满足第三范式要求：

1. 旅程定义主表 journey_definition #

所有旅程节点（不管是作为目标流程还是前置依赖项）统一存在这张主表，避免同一实体多处分存储存不一致的问题：

• journey_code：主键，用固定长度字符串存旅程的唯一标识（比如CUSTOMER/ACCOUNT/SECTOR），查询时无需额外关联即可识别，适合这类枚举属性强、不会频繁修改编码的场景；如果后续旅程编码可能调整，也可以换成自增INT作为主键，额外加journey_code字段做唯一业务标识即可
• journey_name：旅程的可读名称，比如“创建客户档案”“创建银行账户”
• 其他扩展字段（启用状态、创建时间、备注等）可按业务需求自行添加

2. 旅程依赖关联表 journey_prerequisite #

这是多对多关系的中间表，专门存储旅程之间的前置依赖关系：

• journey_code：外键关联主表主键，代表当前要完成的目标旅程
• prerequisite_journey_code：外键关联主表主键，代表目标旅程需要预先完成的前置依赖项（对应你原设计的dependent字段）
• prerequisite_order：INT类型，存储同一目标旅程下，各个前置项的完成顺序，数值越小优先级越高（对应你原设计的order字段）
• 主键采用联合主键：(journey_code, prerequisite_journey_code)，天然保证同一组依赖关系不会重复存储，满足主键非空、唯一的核心要求

必要约束 #

• 两个旅程编码字段都加外键约束，关联主表主键，从数据库层面禁止引用不存在的旅程节点
• 增加检查约束，限制journey_code != prerequisite_journey_code，禁止出现旅程依赖自身的低级逻辑错误
• 如果业务要求同一旅程下的前置项必须严格串行、顺序号不能重复，可额外对(journey_code, prerequisite_order)加联合唯一约束

-- 旅程定义主表
CREATE TABLE journey_definition (
    journey_code VARCHAR(50) PRIMARY KEY COMMENT '旅程唯一编码',
    journey_name VARCHAR(100) NOT NULL COMMENT '旅程显示名称',
    is_active TINYINT(1) NOT NULL DEFAULT 1 COMMENT '是否启用',
    create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) COMMENT '系统旅程定义主表';

-- 旅程依赖关系表
CREATE TABLE journey_prerequisite (
    journey_code VARCHAR(50) NOT NULL COMMENT '目标旅程编码',
    prerequisite_journey_code VARCHAR(50) NOT NULL COMMENT '前置依赖旅程编码',
    prerequisite_order INT NOT NULL DEFAULT 0 COMMENT '前置项执行顺序，数值越小优先级越高',
    create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (journey_code, prerequisite_journey_code),
    FOREIGN KEY (journey_code) REFERENCES journey_definition(journey_code),
    FOREIGN KEY (prerequisite_journey_code) REFERENCES journey_definition(journey_code),
    CONSTRAINT chk_no_self_dependency CHECK (journey_code != prerequisite_journey_code)
) COMMENT '旅程前置依赖关系表';

对应你举的业务场景，先在主表插入所有基础旅程节点：SECTOR、LANGUAGE、COUNTRY、CUSTOMER、ACCOUNT，再在依赖表插入对应关系即可，存储效果和你最初的预期完全一致：

• 完全符合第三范式：不存在传递依赖、冗余存储，不会出现更新异常（比如修改某个旅程编码仅需更新主表单条记录，无需批量修改关联表数据）
• 数据一致性强：外键+检查约束从数据库层挡住无效脏数据
• 查询灵活：如果需要查询某旅程的全链路传递依赖（比如查询创建ACCOUNT需要的所有前置项，包括CUSTOMER依赖的三个基础项），直接用递归CTE即可快速实现
• 扩展性好：后续新增旅程、新增依赖关系无需修改表结构；如果需要给依赖增加属性（比如是否为强依赖、依赖的最低版本要求），直接在关联表加字段即可

注：数据库层面的约束无法自动拦截传递性循环依赖（比如A依赖B、B依赖C、C又依赖A的死循环场景），这类逻辑可以在业务层写入依赖时做递归校验，或通过定时任务定期扫描排查即可，不影响表结构本身的合理性。

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