为什么不主表关联子表，而是子表关联主表外键
在数据库设计中，采用 子表关联主表的外键（即 scene_button_config 关联 scene_basic_info.id，associated_form 关联 scene_button_config.id）是一种符合 范式设计 和 性能优化 的最佳实践，主要有以下几个关键原因：
⸻
- 主表不需要存储过多冗余数据
如果 scene_basic_info 直接存储其子表的数据（比如 scene_button_config 的多个按钮），可能会导致：
• 数据冗余：主表需要存储多个按钮数据，导致重复和存储膨胀。
• 结构不规范：JSON 或字符串拼接存储子数据，违反第一范式（1NF），查询时解析复杂。
• 更新不方便：如修改某个按钮信息，则必须解析和更新整个 scene_basic_info 记录。
优化方案：使用外键让子表 scene_button_config 关联 scene_basic_info，每个按钮作为单独的行存储，使数据更加结构化，避免冗余。
⸻
- 查询性能更优，避免主表频繁修改
• 如果主表 scene_basic_info 直接存储所有 scene_button_config 或 associated_form 数据，
• 查询时需要复杂解析 JSON，降低效率。
• 新增/修改子表数据时，主表频繁更新，导致行锁、MVCC 开销增加，影响并发性能。
• 通过子表外键关联，查询时可以 按需 JOIN，修改子表数据时 不会影响主表，提高整体性能。
示例：查询某个场景的所有按钮
SELECT sbc.*
FROM scene_button_config sbc
JOIN scene_basic_info sbi ON sbc.scene_id = sbi.id
WHERE sbi.scene_name = '某个场景名称';
• 只查询需要的 scene_button_config 数据，不会影响主表的其他字段。
• 索引优化：可以在 scene_button_config.scene_id 上建立索引，提高查询效率。
⸻
- 级联删除更加安全
如果主表存储子表数据，删除时很难控制级联删除逻辑，需要手动解析 JSON 并删除相关数据。
• 现在采用 外键 ON DELETE CASCADE 机制，可以 自动级联删除 相关数据，无需额外逻辑处理：
DELETE FROM scene_basic_info WHERE id = 1;
• 这条 SQL 会自动删除 scene_button_config 和 associated_form 中所有相关数据，避免孤立数据。
⸻
- 事务一致性更好
• 采用子表存储数据时，可以通过事务保证多表数据一致性：
START TRANSACTION;
INSERT INTO scene_basic_info (scene_name, applications, owner, preplan_name, ...) VALUES (...);
SET @scene_id = LAST_INSERT_ID();
INSERT INTO scene_button_config (scene_id, button_name, test_rooms, ...) VALUES (@scene_id, ...);
COMMIT;
• 如果某个步骤失败，可以回滚整个事务，确保数据完整性。
• 如果 scene_basic_info 直接存储 JSON 或数组，事务控制就变得复杂。
⸻
- 更容易扩展 & 维护
• 未来如果 scene_button_config 需要增加更多字段，比如 “按钮执行日志”，只需新增一个表，不会影响 scene_basic_info。
• 采用子表关联方式，可以更灵活地优化索引、分表或缓存，更符合高并发场景下的数据库设计原则。
⸻
总结
方案 优势 劣势
主表存储子表数据（JSON/数组） 结构简单、单表查询快 违反范式，数据冗余，查询和更新复杂，事务难以控制
子表关联主表（外键方式）✅ 数据规范、查询高效、扩展性强、支持事务 需要 JOIN 查询（可通过索引优化）
✅ 采用子表外键关联主表的设计更加规范、安全，并且能提升性能、扩展性和事务一致性。
注：以上内容来自AI
