本文介绍一种更合理、可维护性更强的 django 模型结构，用于表示「必有类型、子类型可选」的题目分类需求，涵盖外键关系优化、`__str__` 安全实现及语义清晰的字段命名。
在 Django 中为「题目（Question）」建模时，若业务逻辑明确要求每个题目必须归属一个类型（Type），而子类型（Subtype）仅为可选补充信息，则原始设计中同时保留 type（指向 QuestionType）和 type_subtype（指向 QuestionSubType）两个外键的做法，虽能工作，但存在冗余、语义不清与潜在一致性风险。
✅ 推荐改进方案：以子类型为核心，类型作为其父级分组
我们应将 QuestionSubType 视为实际分类单元，而 QuestionType 仅作为逻辑分组（如 “选择题”、“填空题”、“解答题”），不再在 Question 中单独保存 type 字段。这样既避免数据重复，又天然保证了「有子类型则必有类型」的一致性约束：
Django Unfold
下载
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
class QuestionType(models.Model):
name = models.CharField(max_length=255, unique=True) # 更语义化的字段名
def __str__(self):
return self.name
class QuestionSubType(models.Model):
type = models.ForeignKey(QuestionType, on_delete=models.PROTECT, related_name='subtypes')
name = models.CharField(max_length=255)
class Meta:
constraints = [
models.UniqueConstraint(fields=['type', 'name'], name='unique_type_subname')
]
def __str__(self):
return f"{self.type.name} → {self.name}" # 清晰体现层级关系对应地，Question 模型精简为：
class Question(QuestionAbstractModel):
chapter = models.ForeignKey(
Chapter,
on_delete=models.SET_NULL,
blank=True,
null=True,
help_text="所属章节（可为空）"
)
subtype = models.ForeignKey(
QuestionSubType,
on_delete=models.SET_NULL, # 推荐 SET_NULL 而非 CASCADE，避免误删导致题目丢失
blank=True,
null=True,
related_name='questions',
help_text="题目子类型（可为空）"
)
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 "无章节"
)
subtype_part = str(self.subtype) if self.subtype else "无子类型（仅基础类型）"
return f"[{chapter_part}] {subtype_part}"⚠️ 关键注意事项
- on_delete 策略选择：对 subtype 使用 models.SET_NULL（需确保字段 null=True），比 CASCADE 更安全；若删除某子类型，题目不会被级联删除，而是降级为“无子类型”，便于后续修复。
- __str__ 健壮性：务必检查 self.chapter 和 self.chapter.subject 是否存在（尤其当 chapter 为 null 时），否则会触发 AttributeError；同理，self.subtype 也需判空。
- 字段命名语义化：用 subtype 替代 type_subtype，用 name 替代 question_type/question_sub_type，提升代码可读性与团队协作效率。
- 数据库约束强化：通过 UniqueConstraint 保证同一类型下子类型名称不重复，防止数据歧义。
✅ 总结
该设计遵循「单一数据源原则」：子类型承载全部分类语义，类型仅作归类容器。它简化了模型关系、规避了跨字段一致性校验难题，并提升了查询与管理的清晰度——例如，获取某类型下的所有题目，只需 QuestionType.objects.get(...).subtypes.all().questions.all()，链式调用自然、高效且意图明确。
