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

EN

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

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

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

• Object-oriented层封装: shorter.
• Persistence 在应用程序中为DB访问提供了一个清晰的层。它将读/写数据所需的所有函数封装在一个点上，这是所谓的DRY (不要重复自己)原则的缩影。这使得一些事情变得容易得多:模型更改，因为所有面向数据库的select和insert/update代码都在一个位置，而不是整个应用程序；安全性，因为所有数据库访问都通过一个位置；测试，因为很容易模拟出您的数据模型和访问，如果它们是明确的delineated.
• SQL安全：虽然很容易保护原始SQL使用，防止注入攻击等，但如果您有一个ORM框架作为单一的DB-contact，为您做这件事，所以您永远不需要考虑它，这就更容易了。

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

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

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

您可以使用select_related() queryset method来减少数据库查询的数量。您还可以指定深度，因此在给定的示例中，如果电话号码模型具有额外的外部关系，您将使用select_related(depth=2)来避免选择更多相关实体的“级别”。