Django中查询抽象父类的特定子类实例：方案性能对比

问题背景 #

模型结构 #

正在构建表示建筑结构的Django模型，逻辑类如下：

• Floor
• BuildingSpace(ABC)（抽象类）
• Office(BuildingSpace)
• CommonArea(BuildingSpace)

功能目标 #

需要在Floor类中实现三类查询方法：

from typing import Type
class Floor(models.Model):
    def getAllSpaces():
        # 返回所有Type[BuildingSpace]类型的对象
    def getAllOffices():
        # 仅返回Type[Office]类型的对象
    def getAllCommonAreas():
        # 仅返回Type[CommonArea]类型的对象

候选解决方案 #

1. django-model-utils：通过InheritanceManager和.select_subclass()实现，要求BuildingSpace为具体类，采用多表继承，会增加查询负载，不支持代理模型。
2. django-polymorphic：通过.instance_of(subclass)实现，代码简洁，但存在性能问题，适配Admin面板难度高。
3. Django原生方案：通过QuerySet.filter()实现，据称性能比上述两个扩展差。
4. 自定义方案：直接调用子类管理器，通过QuerySet.Union实现getAllSpaces()，无额外数据库开销，但需调整模型设计。

待解答问题 #

• django-model-utils、django-polymorphic与最优原生QuerySet.filter()方案在性能上是否有显著差异？
• 这两个扩展还有哪些值得关注的考量因素（易用性、扩展性、额外过滤方式等）？
• 若需求仅局限于上述示例场景，自定义方案是否在性能、易用性、扩展性上表现更优？

解答 #

1. 性能差异对比 #

三者的性能差异核心在于继承实现方式和查询逻辑的冗余度：

• django-model-utils（多表继承）：查询子类时会触发表关联JOIN，数据量越大耗时越明显；但仅查询父类字段时，性能接近原生单表查询。
• django-polymorphic：默认查询会自动关联所有子类表，即使只需要父类数据也会产生冗余查询，大数据量下性能下滑显著；但调用non_polymorphic()方法可跳过子类关联，此时性能与原生多表继承方案持平。
• 原生QuerySet.filter()：若采用抽象类+单表继承（在父类添加space_type字段标记子类类型），查询仅需过滤该字段，属于单表操作，性能最优；若用多表继承，原生filter同样会触发JOIN，性能与django-model-utils一致。

简言之：单表继承的原生方案性能最优，多表继承的原生方案与django-model-utils持平，django-polymorphic默认模式性能最差，手动关闭多态后可追平前两者。

2. 扩展的额外考量因素 #

django-model-utils

• 易用性：上手门槛低，InheritanceManager仅需在父类声明，.select_subclass()语法直观，与原生QuerySet兼容度高。
• 扩展性：支持指定特定子类查询，可结合prefetch_related、annotate等原生方法，但仅支持多表继承，不兼容代理模型和抽象类的多态查询。
• 过滤方式：完全复用原生QuerySet的过滤逻辑，可按父类字段或子类关联字段过滤，无额外学习成本。

django-polymorphic

• 易用性：语法极简，.instance_of(Office)即可直接筛选子类，无需手动处理表关联；但适配Admin面板需要自定义模型、模板和表单，成本较高。
• 扩展性：支持多层级继承场景，能自动处理子类字段的查询与序列化，但与部分第三方库（如DRF序列化器）兼容度一般，需额外适配。
• 过滤方式：支持跨子类字段过滤，例如直接用Office的专属字段过滤父类QuerySet，但会触发额外JOIN，牺牲性能。

3. 自定义方案的适用性（针对当前场景） #

如果需求仅局限于查询Floor关联的空间、办公室、公共区域，自定义方案是最优选择：

• 性能：直接调用子类的objects.filter(floor=self)，再通过Union合并结果，均为单表查询，无额外JOIN开销，性能远优于多表继承的扩展方案。
• 易用性：代码逻辑直观，无需引入第三方依赖，维护成本低；仅需调整模型设计（确保所有子类都包含floor外键），改动量极小。
• 扩展性：后续新增子类（如MeetingRoom(BuildingSpace)）时，只需在getAllSpaces()中新增对应子类的QuerySet并加入Union即可，扩展成本低；但如果需要跨子类字段的复杂查询，灵活性不如django-polymorphic。

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