Django中间表不使用ForeignKey改用IntegerField的利弊分析

先看你提供的模型代码：

class BookTagType(models.Model):
    book_id = models.IntegerField(null=True, blank=True)
    tag_id = models.IntegerField(null=True, blank=True)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        db_table = "book_tag_types"
        managed = False

可能的合理原因/优势 #

• 适配遗留或非Django管理的数据库：从managed = False能看出这张表不受Django迁移管控，大概率是其他系统创建的遗留表。如果原表没建外键约束，用IntegerField可以直接映射，不用修改已有库结构，避免影响依赖该表的其他系统。
• 降低数据库约束的性能开销：高并发写入场景下，外键的存在会触发额外的约束检查（比如验证关联ID是否存在、处理级联操作），用IntegerField能跳过这些检查，提升写入速度。
• 支持跨库/跨服务关联：如果Book和Tag模型不在同一个数据库，甚至分属不同服务，Django的ForeignKey无法直接处理跨库关联，用IntegerField存ID可以手动实现跨服务的关联查询，不受ORM的限制。
• 快速原型或临时过渡需求：搭原型阶段为了快速实现功能，可能先不用ForeignKey；或者需要关联还未正式定义的模型时，IntegerField的灵活性更高。

潜在弊端 #

• 丢失ORM关联操作的便利性：没法使用Django ORM的反向关联（比如book.booktagtype_set.all()）、预取查询（select_related/prefetch_related），所有关联查询都得手动写JOIN或二次查询，代码冗余且易出错。
• 数据库层面无数据完整性保障：没有外键约束，可能插入不存在的book_id或tag_id，导致脏数据。比如删除某本书后，中间表的关联ID还残留，查询时会出现找不到对应Book的情况。
• 无法利用ORM的级联操作：没法通过on_delete参数（如CASCADE、SET_NULL）自动处理关联数据的删除/更新，所有关联数据的清理都得手动编码，增加维护成本。
• 代码可读性与可维护性下降：其他开发者看到IntegerField时，无法直观判断这是关联到哪个模型的ID，需要额外注释或文档说明，容易产生误解。

总结 #

如果是对接遗留系统、跨库关联这类特殊场景，用IntegerField存关联ID是合理的；但如果是纯Django管理的新系统，优先用ForeignKey，既能享受ORM的便利，又能保证数据完整性。

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