Printing a list of persons with more than one home each home with more than one
我尝试过类似模型的答案,这似乎是一种非常低效的方法.每次迭代似乎都会进行单独的查询,有时会导致对数据库的数千次查询.我意识到你可以缓存查询集,但它似乎仍然是非常错误的.所以问题是,你使用那种方法吗？如果没有,你是怎么做到的？
解决方法
我总是觉得记住对象关系映射(ORM)框架解决的一些问题很重要：
>面向对象的CRUD：如果应用程序的其余部分基于强大的面向对象原则,则使用对象访问数据持久性会使代码更加连贯,内部一致,有时更短.
>持久层封装：ORM在应用程序中为数据库访问提供了一个清晰的层.它封装了在一个位置读取/写入数据所需的所有功能,即所谓的DRY(不要重复自己)原则的缩影.这使得一些事情变得更容易：模型更改,因为所有面向数据库的选择和插入/更新代码都在一个位置而不是整个应用程序,安全性,因为所有数据库访问都通过一个位置进行测试,因为它很容易嘲笑你的数据模型和访问权限,如果它们被明确界定.
> sql安全性：虽然很容易保护原始sql使用以防止注入攻击等,但如果你有一个ORM框架作为单点数据库联系人为你做这件事就更容易了,所以你永远不必考虑它.
请注意,速度不在列表中. ORM是代码和数据库之间的间接级别.我们当然要求ORM设计人员负责编写能够生成良好sql语句的框架,但ORM旨在提供代码和体系结构级别的效率,而不是执行效率.阅读过sql基础书籍的开发人员将始终能够获得更好的直接与数据库交流的性能.
肯定有策略可以解决这个问题,而在Django中,那些是像ozan所提到的select_related(),以及site / view / miscellaneous缓存,但它们不会给你与直接sql语句相同的性能.因此,在我需要速度的时候,我永远不会使用ORM框架,它不提供一些机制来发出原始sql语句.例如,在从连接许多表的数据库中生成大型报表时,我经常使用原始sql; ORM方式可能需要几分钟,sql方式可能需要几秒钟.
话虽如此,我从不开始担心每个人的查询.我对任何进入ORM层的人的建议是：不要保护ORM的数据库访问权限.编写应用程序或模块,然后对其进行概要分析,调整那些真正需要性能提升的区域,或者使用缓存/ select_related来减少应用程序的整体DB-chattiness.
