我应该通过任何方式避免 Django 中的多表（具体）继承吗？

许多经验丰富的开发人员建议不要使用Django多表继承由于其性能不佳：

1. Django 陷阱：具体继承 by 雅各布·卡普兰-莫斯，Django 的核心贡献者。

   几乎在所有情况下，抽象继承都是更好的方法 长期来看。我见过不少网站在负载下崩溃了 通过具体继承引入，所以我强烈建议 Django 用户对具体继承的任何使用都有很大的了解。 怀疑的剂量。

2. 两勺姜戈 by 丹尼尔·格林菲尔德 (@pydanny)

   多表继承，有时称为“具体继承”， 作者和许多其他开发人员认为这是一件坏事。 我们强烈建议不要使用它。

   不惜一切代价，每个人都应该避免多表继承 因为它增加了混乱和大量的开销。 使用显式 OneToOneFields 代替多表继承 模型之间的外键，以便您可以控制何时进行连接 穿过。

但如果没有多表继承，我就不能轻易

1. 在另一个模型中参考基础模型（必须使用 GenericForeignKey 或反向依赖）；

2. 获取基础模型的所有实例.

   （欢迎补充）

那么Django中的这种继承有什么问题呢？为什么显式 OneToOneFields 更好？

JOIN 对性能造成多大影响？是否有任何基准可以显示性能差异？

Does not select_related() allow us to control when JOINs are invoked?

我已将具体示例移至单独的问题因为这个变得太宽泛，并添加了一系列使用多表继承的原因。

首先，继承并不能自然地转化为关系数据库架构（好吧，我知道，Oracle 类型对象和其他一些 RDBMS 支持继承，但 django 不利用此功能）

此时，请注意django生成新表到子类并写入lots of left joins从中检索数据‘子表’. And 左连接不是你的朋友。在高性能场景中，例如游戏后端或其他场景，您应该避免它并使用一些工件（例如空值、OneToOne 或外键）“手动”解决继承问题。在OneToOne场景中，您可以直接调用相关表，也可以仅在需要时调用。

... 但 ...

“我认为（TGW）” 当模型继承出现在您的企业项目中时，您应该将其包含在内论域。我这样做了，并且由于此功能，我为客户节省了大量的开发时间。还，代码变得干净优雅这意味着易于维护（请注意，此类项目每秒不会有数百个或请求）

逐个问题

问：Django中这种继承有什么问题吗？
答：很多表，很多左连接。

问：为什么显式 OneToOneFields 更好？
A：您可以直接访问相关模型，无需左连接。

问：有没有任何说明性示例（基准）？
答：没有可比性。

问：select_lated() 不允许我们控制 JOIN 何时被调用吗？
答：django 连接所需的表。

问：当我需要引用另一个模型中的基类时，多表继承的替代方法是什么？
答：无效化。一对一关系和大量代码行。这取决于应用需求。

问：在这种情况下 GenericForeignKey 更好吗？
答：不适合我。

问：如果我需要 OneToOneField 作为基础模型怎么办？
答：写吧。这没有问题。例如，您可以扩展用户模型，也可以为某些用户建立一对一到用户的基础模型。

结论

您应该了解在没有模型继承的情况下编写和维护代码的成本，以及支持模型继承应用程序并采取相应行动的硬件成本。

开个玩笑：你可以把它写在汇编代码上，它会运行得更快。

Quoting 特雷·亨纳:

您的时间通常比 CPU 的时间贵得多。