【后端】【Django orm】多对多关系建议使用自定义中间表,避免语义不清晰

Djnago 的orm多对多关系自动生成时,models.ManyToManyField 可以定义在任意一方,但确实可能会导致模型的可读性变差,甚至让代码逻辑变得不直观。


多对多字段定义在哪一方?

Django 在任意一方 定义 ManyToManyField 都可以,但有些情况会导致模型语义不清晰,影响代码可读性。例如:

python 复制代码
class Student(models.Model):
    name = models.CharField(max_length=100)
    courses = models.ManyToManyField("Course")  # 定义在 Student 侧

    def __str__(self):
        return self.name

class Course(models.Model):
    title = models.CharField(max_length=200)

    def __str__(self):
        return self.title

上面代码等价于:

python 复制代码
class Course(models.Model):
    title = models.CharField(max_length=200)
    students = models.ManyToManyField("Student")  # 定义在 Course 侧

    def __str__(self):
        return self.title

无论 ManyToManyField 定义在 Student 还是 Course ,Django 都会自动创建一张中间表,效果是一样的。


为什么"任意一方"会感觉怪?

虽然 Django 允许 ManyToManyField 定义在任意一方,但有时候会让模型的语义不直观,例如:

  • 从业务逻辑来看,关系的主动性不同 。有些关系更容易被理解为谁拥有谁
  • 模型结构可能不符合直觉,让代码的可读性变差。

示例 1(好的设计:选课系统)

学生(Student)选择课程(Course) ,语义上 学生拥有课程 更合理,所以 ManyToManyField 应该定义在 Student 侧:

python 复制代码
class Student(models.Model):
    name = models.CharField(max_length=100)
    courses = models.ManyToManyField("Course", related_name="students")  # 推荐定义在 Student 侧

    def __str__(self):
        return self.name

class Course(models.Model):
    title = models.CharField(max_length=200)

    def __str__(self):
        return self.title

这样,在查询的时候:

python 复制代码
student.courses.all()  # 获取某个学生选的课程
course.students.all()  # 反向查询某门课程的学生

语义清晰,可读性更好。


示例 2(不直观的设计)

如果 ManyToManyField 定义在 Course 侧:

python 复制代码
class Student(models.Model):
    name = models.CharField(max_length=100)

    def __str__(self):
        return self.name

class Course(models.Model):
    title = models.CharField(max_length=200)
    students = models.ManyToManyField("Student")  # 定义在 Course 侧

    def __str__(self):
        return self.title

在查询 student.courses.all() 时,Django 需要依赖反向查询 ,而 student 本身没有 courses 属性,会降低代码的直观性:

python 复制代码
student.courses.all()  ❌  # AttributeError: 'Student' object has no attribute 'courses'

student.course_set.all() ✅  # 需要反向查询

这种情况下,把 ManyToManyField 定义在 Student 侧更符合直觉。


什么时候用中间表?

多对多关系包含额外字段 (如选课成绩、加入时间),就不能使用 Django 自动生成的中间表,需要手动定义中间表

python 复制代码
class Student(models.Model):
    name = models.CharField(max_length=100)

    def __str__(self):
        return self.name

class Course(models.Model):
    title = models.CharField(max_length=200)

    def __str__(self):
        return self.title

class Enrollment(models.Model):  # 手动中间表
    student = models.ForeignKey(Student, on_delete=models.CASCADE)
    course = models.ForeignKey(Course, on_delete=models.CASCADE)
    grade = models.CharField(max_length=10, blank=True, null=True)  # 额外字段
    enrolled_at = models.DateTimeField(auto_now_add=True)

这样查询会更灵活:

python 复制代码
# 获取某个学生的所有选课记录
Enrollment.objects.filter(student=student).values("course__title", "grade")

总结

  1. ManyToManyField 可以定义在任意一方,但应该选择语义更清晰的那一方:

    • 推荐 :在"主动"关联的一方定义,比如 学生 -> 课程
    • 避免 :在关系不直观的一方定义,比如 课程 -> 学生
  2. 如果需要存储额外信息(如选课成绩) ,应该使用手动中间表

  3. 查询方便性

    • related_name="students" 可以让 course.students.all() 变得直观。
    • 直接用 ManyToManyField 自动生成的中间表,不需要手动管理关系表。

最佳实践 :如果你发现 ManyToManyField 定义的位置让代码逻辑变怪,就考虑是否换一方定义,或者改用手动中间表

相关推荐
zhangsan093341 分钟前
web框架(Django 与 FastAPI)
django·fastapi
敖云岚1 小时前
【Redis】分布式锁的介绍与演进之路
数据库·redis·分布式
LUCIAZZZ2 小时前
HikariCP数据库连接池原理解析
java·jvm·数据库·spring·springboot·线程池·连接池
我在北京coding2 小时前
300道GaussDB(WMS)题目及答案。
数据库·gaussdb
小Tomkk2 小时前
阿里云 RDS mysql 5.7 怎么 添加白名单 并链接数据库
数据库·mysql·阿里云
明月醉窗台3 小时前
qt使用笔记二:main.cpp详解
数据库·笔记·qt
Python智慧行囊3 小时前
Python 中 Django 中间件:原理、方法与实战应用
python·中间件·架构·django·开发
沉到海底去吧Go3 小时前
【图片自动识别改名】识别图片中的文字并批量改名的工具,根据文字对图片批量改名,基于QT和腾讯OCR识别的实现方案
数据库·qt·ocr·图片识别自动改名·图片区域识别改名·pdf识别改名
老纪的技术唠嗑局4 小时前
重剑无锋,大巧不工 —— OceanBase 中的 Nest Loop Join 使用技巧分享
数据库·sql
未来之窗软件服务4 小时前
JAVASCRIPT 前端数据库-V6--仙盟数据库架构-—-—仙盟创梦IDE
数据库·数据库架构·仙盟创梦ide·东方仙盟·东方仙盟数据库