|
|
4 回复 | 直到 15 年前
|
1
6
对于您的问题,有很多事情需要假设,因为您没有任何类型的代码示例。 以下是我的假设:您使用的是Django的内置ORM工具和模型(即sales data=modelobj.objects().all()),在PHP方面,您处理的是直接的SQL查询和查询集。 Django正在进行大量类型转换和转换,将数据类型从数据库查询转换为ORM/模型对象和关联的管理器(默认情况下为objects())。 在PHP中,您控制转换并确切知道如何从一种数据类型转换为另一种数据类型,您只需根据该问题节省一些执行时间。 我建议您尝试将一些花哨的数字工作转移到数据库中,特别是在您正在进行基于记录集的处理时——数据库会从早餐开始接受这种处理。在Django中,可以将原始SQL发送到数据库: http://docs.djangoproject.com/en/dev/topics/db/sql/#topics-db-sql 我希望这至少能让你找到正确的方向… |
|
|
2
2
“tokenize.py出现在最前面,这可能有一些意义,因为我正在进行大量的数字格式设置。” 完全没有意义。 见 http://docs.python.org/library/tokenize.html .
标记化出现在顶部意味着您正在进行动态代码解析。 Afaik(在Django存储库中进行搜索)Django不使用标记化。这样您的程序就可以进行某种动态代码实例化。或者,你只是在分析 第一 程序加载、分析和运行的时间,导致错误的时间假设。 你应该 不 曾经在模板标记中进行过计算——这很慢。它涉及模板标记的复杂元评估。您应该使用简单、低开销的Python在视图中进行所有计算。仅将模板用于演示文稿。 此外,如果您经常进行查询、筛选、求和等操作,那么您就有了一个数据仓库。获取一本关于数据仓库设计的书,并遵循数据仓库设计模式。 必须有一个中央事实数据表,由维度表包围。这是非常,非常有效的。
总和、分组依据等可作为
|
|
|
3
2
在处理大数据集时,还可以使用 ValuesQuerySet 它更直接地访问查询结果,而不是为结果中的每一行创建模型对象实例。 它的用法看起来有点像这样: |
|
|
4
1
在这种情况下,数据库往往是瓶颈。此外,使用ORM可能会导致次优的SQL查询。 正如一些人指出的那样,仅仅凭你提供的信息是不可能说出问题的实质的。 我可以给你一些一般性的建议:
附言:仅供参考,我曾经有一个相当简单的观点,这是非常缓慢的。安装后 调试页脚中间件 我在500左右看到的!SQL查询是在该单一视图中执行的。只是使用 选择“相关”() 将其归结为5个查询,并按预期执行视图。 |
