我有一个与PostgreSQL数据库连接的Django项目;我的一个表大约有450行,每行包含大约十几列。
每个列的值必须放在不同的公式中以生成我想要在模板层中显示的最终数据,但每行都将使用相同的计算集进行处理。 (换句话说,我想每次执行12次不同的计算450次。)
我的问题是,在以下方法中,这是普遍接受的方法,这在性能方面是最好的:
A)将每个计算写为models.py中的模型方法,在views.py中查询所有感兴趣的对象(同样,大约450个)并将它们直接传递给模板,然后使用Django的模板语言编写比如:
<table>
{% for item in list %}
<tr>
<td>{{item.name}}</td>
...
</tr>
{% endfor %}
</table>
(其中.name
是模型方法)
B)在views.py文件中执行查询和计算,并将组织成一个大字典或列表或JSON的结果传递给模板(然后使用模板标记对其进行解析),< / p>
C)将所有感兴趣的对象传递给模板,如A)中所示,但是使用Javascript或jQuery对每个对象的字段执行计算,
D)结合B)和C)在views.py中执行所有数据库查询,然后将 raw 值作为大字典/列表/ JSON对象传递给模板,并对这些值进行计算使用Javascript / jQuery的值。
在我看来,方法A)似乎效率最低,因为它要求你在模板层中多次访问数据库。但它使编写视图和模板非常简单(只需要编写12种不同的模型方法)。方法B)似乎遵循在视图中尽可能多地执行逻辑的一般原则,并简单地传递最终结果以显示在模板中。但它使视图功能变得冗长而丑陋。方法C)和D)将大部分负载放在最终用户的浏览器上,这似乎真的可以减轻服务器的负担,但是如果用户已关闭JS,那么显然不会起作用。
但同样,我想知道是否有针对这种情况的公认最佳做法,以及这是否与计算方面的最快方法相矛盾。
显然,如果我错过了最好的方法,请告诉我它会是什么。
答案 0 :(得分:2)
方法(C)和(D),虽然诱人不是要走的路。客户端的计算机可能很慢,在这种情况下,页面可能会在执行所有这些计算时冻结浏览器。
(A)似乎是最好的选择,它不应该在其他查询中产生。如果你将对象传递给单个查询集中的模板(例如Model.objects.all()),那么Django应该执行单个查询来获取所有对象,然后在模板中调用方法时,不应该有额外的查询被执行。如果您的对象与其他对象相关,并且在计算中使用了此关系,请确保使用select_related或prefetch_related,因为在每个模型调用上查询相关对象确实会在每个对象的单个查询中产生,除非您预取/选择“事先重新使用(https://docs.djangoproject.com/en/dev/ref/models/querysets/#select-related)。