Django Generic Foreign keys - 考虑到SQL性能的好坏？

Question

我有一个模型A ，它包含一个通用的外键关系，在同一个应用程序中有3个其他模型（将它们视为B ， C和D ）的限制选择。 我知道通用外键的局限性，我们不能使用filter或get或任何其他查询集操作。

所以要实现这样的东西， A.objects.filter(generic_object__name="foo")我必须首先过滤B，C和D的对象作为查询集，迭代它们并使用通用反向关系将A对象作为列表（不是查询集）。

我不确定它将如何影响数据库上的SQL性能，因为查询不是直接的。

PS：我需要使用通用的外键，所以请建议任何SQL改进而不是重新设计模型。

使用Django 1.4.3和Postgres。

Answer 1

我想引用David Cramer的一些话：Disqus的开发者，Django委员

通用关系很好。 它们并不慢，在您的代码库中管理起来更加困难。

我看到很多人告诉别人不要使用通用关系，因为它很慢，但从不告诉它如何缓慢。

Answer 2

避免Django的GenericForeignKey对通用外键中涉及的数据库设计反模式（或“多态关联”，如他们称之为rails-speak）进行了详尽而详尽的描述。

至于性能，每次要从模型中检索相关的GenericForeignKey资源时，它需要3个数据库查询：

SELECT object_id_field，来自myapp_a的object_id WHERE id = 1;
SELECT app_label，model FROM django_content_type WHERE id = A.object_type_field;
- 在应用程序代码中，计算表名model + _ + app_label
从TABLE_NAME选择A.object_id_field;

当人们说通用外键具有性能损失时，他们会引用此查询开销。

只有非常狭窄的环境，您真正想要使用通用外键。 上面链接的文章也讨论了这些内容。

Answer 3

在模型中添加index_together Meta选项：

class Meta:
    index_together = [('cprofile_id', 'cprofile_type')]