一对多关系中外键必须建在“多”的一方并配索引、非空约束和引用完整性；如order_items表设order_id外键指向orders，禁用字符串拼接等反模式。
一对多关系是数据库设计中最常见的关联类型，建模是否合理直接影响查询性能、数据一致性和维护成本。核心原则是：外键必须建在“多”的一方，且需配合索引、非空约束和引用完整性控制。
外键必须放在“多”端表中
例如订单（orders）与订单项（order_items）是一对多：一个订单可含多个商品项，但一个订单项只属于一个订单。此时 order_items 表中必须包含 order_id 字段作为外键，指向 orders 表的主键。
- 错误做法：在 orders 表里加一个“item_ids”字符串字段拼接多个ID——破坏第一范式，无法索引、无法约束、难以查询
- 正确做法：order_items.order_id NOT NULL REFERENCES orders(id)，确保每个订单项都归属明确且合法的订单
外键字段必须建立索引
数据库在 JOIN、DELETE 级联、外键检查时会频繁查找外键值。若 order_items.order_id 无索引，删除某个订单时可能触发全表扫描，导致锁表和性能骤降。
- MySQL/PostgreSQL：显式创建索引，如 CREATE INDEX idx_order_items_order_id ON order_items(order_id)
- 注意：主键自动索引，但外键字段不自动索引，必须手动添加
- 复合查询常用场景（如按用户查最近10个订单及其所有明细），可考虑联合索引：(user_id, created_at, order_id)
根据业务语义决定是否允许 NULL 和级联行为
外键字段是否允许为 NULL，取决于“多”端记录能否独立存在。例如：员工表（employees）与部门表（departments）是一对多，但员工可以暂无部门（如刚入职待分配），此时 department_id 可设为 NULL；而订单项绝不能脱离订单，order_id 必须 NOT NULL。
ECTouch是上海商创网络科技有限公司推出的一套基于 PHP 和 MySQL 数据库构建的开源且易于使用的移动商城网店系统！应用于各种服务器平台的高效、快速和易于管理的网店解决方案，采用稳定的MVC框架开发，完美对接ecshop系统与模板堂众多模板，为中小企业提供最佳的移动电商解决方案。ECTouch程序源代码完全无加密。安装时只需将已集成的文件夹放进指定位置，通过浏览器访问一键安装，无需对已有
- ON DELETE RESTRICT（默认）：禁止删除被引用的父记录，适合强一致性场景（如删除客户前必须清空其订单）
- ON DELETE CASCADE：自动删除子记录，适用于生命周期严格绑定的场景（如临时会话 session → session_data）
- 避免 ON DELETE SET NULL，除非业务明确允许“孤儿记录”，否则易引发逻辑歧义和统计偏差
避免反模式：用单字段模拟一对多
常见错误包括：在父表中用逗号分隔的字符串存子ID（如 tags = '1,5,9'）、用 JSON 数组存子数据（如 items = '[{"id":1,"qty":2}]'）。这类设计看似简洁，实则严重损害：
- 查询能力：无法高效 WHERE item_id = 5，无法 JOIN，无法利用索引
- 数据完整性：无法保证子项真实存在，无法强制非空或唯一约束
- 事务安全：更新子集合需应用层拆解，易出现部分成功、部分失败
- 扩展性：当需要对子项单独加状态、时间戳、权限等属性时，模型立即崩溃
不复杂但容易忽略：外键不是摆设，它需要索引支撑、约束保障和语义对齐。只要把外键放对位置、加上索引、选好删除策略，一对多就稳了。
