进阶设计指南之如何添加表之间关联关系_支持高级扩展类型-navicat-PHP中文网

ORM外键关联需规范声明字段名、on_delete行为（如SET_NULL配null=True）和related_name（如'orders'）；ManyToManyField扩展需自定义中间模型；JOIN性能优化重在索引与精简字段；JSONB动态关联受限于无外键、索引难、JOIN差。

orm 里加关联不是光写个 foreignkey 就完事，关键是字段名、on_delete 行为、反向关系名这三项必须对齐业务逻辑。

常见错误现象：查 User 对应的 Order 时返回空列表，但数据库里明明有数据；或者删用户时报 ProtectedError。

on_delete 别无脑用 CASCADE —— 如果订单要归档保留，该用 SET_NULL，且对应字段得加 null=True
反向关系名（related_name）别留默认值 '%(class)s_set'，否则 user.order_set.all() 这种写法难读又易错，建议显式设成 related_name='orders'
如果关联的是软删除模型（比如带 is_deleted 字段），记得在查询时手动加过滤，ORM 不会自动跳过“已删除”记录

原生 ManyToManyField 只存 ID 对，一旦需要记录“何时添加”“权重”“状态”等扩展信息，就必须拆成显式的中间模型。

使用场景：用户和标签之间不只是“有/无”关系，还要记打标时间、人工审核状态、置信度分数。

去掉原来的 tags = ManyToManyField(Tag)，改用 tags = ManyToManyField(Tag, through='UserTag')
UserTag 模型里至少得包含两个 ForeignKey：分别指向 User 和 Tag，且联合唯一（unique_together = ('user', 'tag')）
通过中间模型查数据时，不能直接用 user.tags.all() 获取带扩展字段的结果，得走 UserTag.objects.filter(user=user).select_related('tag')

ORM 自动生成的 JOIN 很容易嵌套过深，尤其带 prefetch_related 或 select_related 时，一张表连五层，查询耗时从 20ms 涨到 1.2s 是常态。

根本原因不是 JOIN 本身慢，而是数据库没走索引，或返回了大量冗余字段。

检查每层 JOIN 字段是否有索引 —— 特别是外键列和 related_name 对应的字段，没索引就加 db_index=True
避免在 select_related 里跨多个一对多关系（比如 select_related('profile__address__city')），这种链式调用会让 SQL 膨胀极快
真要查多层关联数据，优先考虑用原生 SQL 或 values()/values_list() 显式指定字段，减少传输和序列化开销

有些场景不适合建新表（比如客户自定义字段、临时实验性关联），用 JSONB 存 ID 列表看似灵活，但很快会撞上三个硬限制。

典型错误现象：按某个关联 ID 查记录时，发现无法走索引、没法做外键约束、JOIN 写起来像解谜。

JSONB 里的 ID 列表不支持数据库级外键，应用层得自己校验引用完整性，漏一次就脏数据
想按某个 ID 查所有含它的记录？得用 @> '{"id": 123}'，这种操作 PostgreSQL 无法用普通 B-tree 索引加速，得建 GIN 索引，而且只对整个 JSON 结构有效
和其它表 JOIN 时，得用 jsonb_array_elements() 展开，性能差、语法丑、ORM 基本不支持，最后往往退回到应用层双查

真正需要动态结构时，先评估是否能用标准多对多 + 状态字段替代；JSONB 只适合读多写少、不参与复杂关联、且能接受弱一致性的场景。