sql - 关于 Django 中的嵌套集合和查询效率的问题

Question

我看到很多这样的答案:

Printing a list of persons with more than one home each home with more than one

我已经用类似的模型尝试过这个答案，这似乎是一种非常低效的方法。每次迭代似乎都会进行单独的查询，有时会导致对数据库的数千次查询。我意识到您可以缓存查询集，但它似乎仍然非常错误。那么问题来了，你用的是那种方法吗？如果没有，你怎么做？

Answer 1

这是一个很好的问题，而且不限于 Django 的 ORM 框架。

我总觉得记住对象关系映射 (ORM) 框架解决的一些问题很重要:

面向对象的 CRUD :如果应用程序的其余部分基于强大的面向对象原则，那么使用对象访问数据持久性会使代码更加连贯、内部一致，有时甚至更短。

持久层封装 :ORM 在您的应用程序中为 DB 访问提供了一个清晰的层。它将读取/写入数据所需的所有功能封装在一处，这就是所谓的 DRY(不要重复自己)原则的缩影。这使得一些事情变得更容易:模型更改，因为所有面向 DB 的选择和插入/更新代码都在一个位置而不是整个应用程序中，安全性，因为所有数据库访问都通过一个位置，以及测试，因为它很容易模拟您的数据模型并在明确描述时进行访问。

SQL 安全 :虽然很容易保护原始 SQL 的使用免受注入(inject)攻击等，但如果您有一个 ORM 框架作为 DB-contact 的单点来为您做这件事，那么您就不必考虑它了，这会更容易。

请注意，速度不在列表中。 ORM 是代码和数据库之间的间接级别。我们当然要求 ORM 设计人员负责编写能够生成良好 SQL 语句的框架，但 ORM 旨在提供代码和架构级别的效率，而不是执行效率。阅读过 SQL 基础书籍的开发人员将始终能够获得更好的性能，直接与 DB 对话。

当然有一些策略可以解决这个问题，在 Django 中，这些策略是 select_related()正如 ozan 所提到的，以及站点/ View /杂项缓存，但它们不会为您提供与直接 SQL 语句相同的性能。因此，当我需要速度时，我永远不会使用不提供某种机制来发出原始 SQL 语句的 ORM 框架。例如，在从连接许多表的数据库中生成大型报告时，我经常使用原始 SQL； ORM 方式可能需要几分钟，SQL 方式可能需要几秒钟。

话虽如此，我从不担心每个单独的查询。我对任何来到 ORM 层的人的建议是:不要保姆 ORM 的数据库访问。编写您的应用程序或模块，然后对其进行分析，调整那些真正需要提高性能的区域，或使用缓存/select_related 来减少应用程序的整体 DB-chatiness。