Django：ForeignKey vs related_name

Question

我想问一下以下两种表达ForeignKey关系的方式之间是否有重要区别，还是只是“风格”差异？

先定义零件然后收集零件似乎很直观； 一个“子模型”，然后在填充“主模型”时使用这个“零件表”。 因此， Album_1 model 从Track_1表（集合由部分组成）中获取单个或多个轨道，如下所示。

版本_1

class Track_1(models.Model):
    order = models.IntegerField()
    title = models.CharField(max_length=100)
    duration = models.IntegerField()

class Album_1(models.Model):
    album_name = models.CharField(max_length=100)
    artist = models.CharField(max_length=100)
     # if Album only holds one (1) track,
    tracks = models.ForeignKey(Track_1, on_delete=models.CASCADE) 
     # if the "record"/"Album" holds several tracks
    tracks = models.ManyToManyField(Track_1, blank=True)

同时，将其表达如下不太直观，可以将其口头解释为Track_2包含一个Album_2 （该部分由一个集合组成）。

版本_2

 class Album_2(models.Model):
    album_name = models.CharField(max_length=100)
    artist = models.CharField(max_length=100)
    
 class Track_2(models.Model):
    album = models.ForeignKey(Album_2, related_name='tracks', on_delete=models.CASCADE)
    order = models.IntegerField()
    title = models.CharField(max_length=100)
    duration = models.IntegerField()

我已经多次看到这种差异，我很好奇为什么经常使用看似不直观的“version_2”，例如与 Django Rest 框架有关？

Answer 1

我想说你混合了这些概念：外键定义了模型之间的关系，而related_name 是外键的一个属性，它定义了你将如何引用相关的 model （主要是为了方便）。

这里重要的是外键，因为它定义了应用程序的业务逻辑。 我会说 version_1 model 从业务逻辑的角度来看是有问题的，而 version_2 是有道理的。

让我解释一下，我将从版本 2 开始： 在 version_2 中，您说：我的主要 model 是专辑，如果我删除特定专辑，则该专辑中的所有曲目都将从曲目表中删除。 说得通！

在 version_2 中，您说我的主要 model 是 Track，如果我从 Track 表中删除一首曲目，则包含该特定曲目的所有专辑都将更新，因为该曲目将从包含它的所有专辑中删除。 是否有意义？ 也许在某些特殊情况下是的，但总的来说这没有意义。

Answer 2

我认为这里的答案是@Blusky 在评论之一中指出的，他写道：

[...] 反向名称是简化 ORM 使用的“技巧”，但该字段未在数据库中创建