Django 模型设计：如何优雅处理带可选子类型的题目分类结构

本文介绍一种更合理、健壮的 Django 模型设计方案，用于表示“必有类型、可选子类型的题目分类关系，涵盖外键建模优化、`__str__` 安全实现及数据一致性保障。

在 Django 应用中，当业务模型需要表达「层级分类」关系（如题目必须属于某一大类，但可进一步细分为可选的子类）时，直接为顶层类型和子类型分别建立独立外键，虽直观却易引发冗余与逻辑矛盾。你当前的设计中，Question 同时持有 type（必填）和 type_subtype（可空）两个外键，这隐含了数据不一致风险：例如，一个 QuestionSubType 实例所属的 QuestionType 与 Question.type 可能不匹配，破坏分类完整性。

更优解是以子类型为事实中心——即 Question 仅通过 type_subtype 关联到 QuestionSubType，而 QuestionSubType 自身通过外键关联到 QuestionType。这样既保证了类型归属的唯一性，又自然支持「无子类型」场景（通过允许 type_subtype 为空），同时消除了跨字段校验负担。

以下是重构后的推荐模型结构：

class QuestionType(models.Model):
    name = models.CharField(max_length=255, unique=True)  # 建议使用更语义化的字段名

    def __str__(self):
        return self.name

class QuestionSubType(models.Model):
    question_type = models.ForeignKey(
        QuestionType,
        on_delete=models.CASCADE,
        related_name='subtypes'
    )
    name = models.CharField(max_length=255)

    class Meta:
        constraints = [
            models.UniqueConstraint(
                fields=['question_type', 'name'],
                name='unique_type_subname'
            )
        ]

    def __str__(self):
        return f"{self.question_type.name} → {self.name}"

class Question(QuestionAbstractModel):
    chapter = models.ForeignKey(
        Chapter,
        on_delete=models.SET_NULL,
        blank=True,
        null=True,
        related_name='questions'
    )
    type_subtype = models.ForeignKey(
        QuestionSubType,
        on_delete=models.SET_NULL,  # 推荐使用 SET_NULL 而非 CASCADE，避免误删题目
        blank=True,
        null=True,
        related_name='questions'
    )
    solution_url = models.URLField(max_length=555, blank=True)

    def __str__(self):
        # 安全拼接：所有可能为 None 的字段均做显式判断
        chapter_part = (
            f"{self.chapter.subject.grade} {self.chapter.subject.name} {self.chapter.name}"
            if self.chapter and self.chapter.subject
            else "No Chapter"
        )
        subtype_part = str(self.type_subtype) if self.type_subtype else "No Subtype"
        return f"{chapter_part} — {subtype_part}"

关键改进说明：

• ✅ 单一可信源：Question 不再维护独立的 type 字段，类型信息完全由 type_subtype.question_type 提供，避免数据二义性；
• ✅ 健壮的 __str__：对 self.chapter、self.chapter.subject 和 self.type_subtype 均做存在性检查，防止 None 引发 AttributeError；
• ✅ 更安全的级联行为：将 on_delete=models.SET_NULL 应用于 chapter 和 type_subtype，确保删除章节或子类型时题目仍可保留（需对应字段设为 null=True）；
• ✅ 增强约束与可读性：QuestionSubType 添加联合唯一约束，防止同一类型下重复子类名；字段命名统一为 name，语义更清晰；
• ✅ 正向反向关系明确：通过 related_name 显式定义反向关系（如 question_type.subtypes.all()），提升查询可读性。

最后提醒：若业务中存在大量“仅有类型、无子类型”的题目，还可考虑为 QuestionSubType 添加一个全局占位实例（如 Uncategorized），让 type_subtype 始终非空，从而简化前端逻辑——但这属于权衡取舍，需结合实际查询频次与一致性要求决定。