Django GenericForeignKey 与一组 ForeignKey答案

【问题标题】：Django GenericForeignKey vs set of ForeignKeyDjango GenericForeignKey 与一组 ForeignKey
【发布时间】：2019-07-05 08:44:33
【问题描述】：

我想讨论一下使用 GenericRelation 和 GenericForeignKey 的情况。

我有 2 个模型，Appartement 和 Mission。我需要创建将连接到 Appartment 或 Mission 的 LockCode 模型。我已将 GenericForeignKey 添加到 LockCode 和 GenericRelation 到 Appartement 和 Mission：

class LockCode(TimeStampedModel):
    context_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
    context_id = models.PositiveIntegerField()
    context = GenericForeignKey('context_type', 'context_id')


class Mission(DirtyFieldsMixin, models.Model):
    lock_codes = GenericRelation(
        LockCode,
        content_type_field='context_type',
        object_id_field='context_id',
        related_query_name='mission'
    )

class Appartment(DirtyFieldsMixin, models.Model):
    lock_codes = GenericRelation(
        LockCode,
        content_type_field='context_type',
        object_id_field='context_id',
        related_query_name='appartment'
    )

它工作正常。但增加了复杂性级别，以与添加 2 个外键（用于公寓和任务）进行比较。

class LockCode(TimeStampedModel):
  appartement = models.ForeignKey(Appartement, null=True, blank=True)
  mission = models.ForeignKey(Mission, null=True, blank=True)

那么我应该保留GFK还是使用2个简单的FK？

【问题讨论】：

标签： django foreign-keys generic-foreign-key

【解决方案1】：

如果您选择第二个选项，则必须构建逻辑以确保 appartement 或 mission 不是 null。如果你要添加更多这样的外键字段，这个逻辑会变得越来越复杂。

如果您确定永远不会添加更多外键，并且不介意确保其中一个不是 null 的开销，那么您可以继续使用外键，但为了可扩展性，我会坚持泛型关系。

【讨论】：

是的，现在我确信 99% 不会有更多的对象。感谢您的回复！

【解决方案2】：

复杂性并非都发生在字段定义中。它也发生在查询时：给定一个 LockCode，你如何确定它属于公寓还是任务？使用两个外键，您需要每次都检查并捕获任何异常。

如果您永远不需要以这种方式遵循关系，那么是的，GFK 是不必要的，两个 FK 会更好。

【讨论】：

感谢您的回复！ “你怎么确定它是属于公寓还是任务？” - 现在它是 2 个不同的端点。 IE 我知道我通过了 Mission 或 Appartement。我尝试使用 GFK 不为每个模型添加多个 FK（老实说，这是一种 Rails 方式，我以前做过）。我决定使用两个 FK，以免在项目中增加额外的复杂性。