Question

我有以下脚本来获取特定日期后每天的计算索引列表：

with test_reqs as (
 select id_test, date_request, sum(n_requests) as n_req from cdr_test_stats
 where
 id_test in (2,4) and -- List of Ids included in index calc
 date_request >= 20170823 -- Start date (end date -> Last in DB -> Today)
 group by id_test, date_request
),
date_reqs as (
 select date_request, sum(n_req) as n_req
 from test_reqs
 group by date_request
),
test_reqs_ratio as (
 select H.id_test, H.date_request, 
 case when D.n_req = 0 then null else H.n_req/D.n_req end as ratio_req
 from test_reqs H
 inner join date_reqs D
 on H.date_request = D.date_request
),
test_reqs_index as (
 select HR.*, least(nullif(HA.n_dates_hbalert, 0), 10) as index_hb
 from test_reqs_ratio HR
 left join cdr_test_alerts_stats HA
 on HR.id_test = HA.id_test and HR.date_request = HA.date_request
)
select date_request, 10-sum(ratio_req*index_hb) as index_hb
from test_reqs_index
group by date_request

结果：

---------------------------
| date_request | index_hb |
---------------------------
|   20170904   |  7.5508  |
|   20170905   |  7.6870  |
|   20170825   |  7.4335  |
|   20170901   |  7.7116  |
|   20170824   |  1.6568  |
|   20170823   |  0.0000  |
|   20170903   |  5.1850  |
|   20170830   |  0.0000  |
|   20170828   |  0.0000  |
---------------------------

问题是我希望在Django中获得相同的效果，并且避免使用游标执行原始查询。

非常感谢任何建议。

Answer 1

如果不深入讨论细节，我会说Django ORM有足够的表现力来处理大多数问题，但一般来说，需要你从头开始重新设计查询。您将不得不使用子查询和连接而不是CTE，并且最终可能会得到一个解决方案，它可以在Python中执行某些工作而不是DB。

考虑到这一点，答案是：依赖。您的功能要求（如性能和数据大小）起着重要作用。

另一个值得考虑的解决方案是将您的SQL查询声明为视图，至少在Postgres的情况下，使用django-pgviews之类的东西来使用Django ORM查询它，就好像它是一个模型一样。

是否可以使用Django进行复杂的SQL查询？

1 个答案: