在使用PostgreSQL 9.3.10的游戏中,一些玩家已经支付了一个" VIP状态",这是由包含未来日期的 vip 列表示的:
# \d pref_users
Column | Type | Modifiers
------------+-----------------------------+--------------------
id | character varying(32) | not null
first_name | character varying(64) | not null
last_name | character varying(64) |
vip | timestamp without time zone |
玩家也可以通过将漂亮的列设置为 true , false 或将其留在 null 来为其他玩家评分:
# \d pref_rep
Column | Type | Modifiers
-----------+-----------------------------+-----------------------------------------------------------
id | character varying(32) | not null
author | character varying(32) | not null
nice | boolean |
我计算了一个"声誉"发出此SQL JOIN语句的VIP-players:
# select u.id, u.first_name, u.last_name,
count(nullif(r.nice, false))-count(nullif(r.nice, true)) as rep
from pref_users u, pref_rep r
where u.vip>now()and u.id=r.id group by u.id order by rep asc;
id | first_name | last_name | rep
-------------------------+--------------------------------+--------------------
OK413274501330 | ali | salimov | -193
OK357353924092 | viktor | litovka | -137
DE20287 | sergej warapow |
我的问题是以下内容:
如何找到所有评级为其他玩家的负面评分玩家?
(背景是我已经为所有VIP玩家增加了评价其他人的可能性。在此之前,只有正面评价的玩家可以评价其他玩家。)
我尝试了以下操作,但收到以下错误:
# select count(*) from pref_rep r, pref_users u
where r.author = u.id and u.vip > now() and
u.id in (select id from pref_rep
where (count(nullif(nice, false)) -count(nullif(nice, true))) < 0);
ERROR: aggregate functions are not allowed in WHERE
LINE 1: ...now() and u.id in (select id from pref_rep where (count(null...
^
更新
我正在尝试使用临时表 -
首先我填写所有负面评价的VIP用户,这很有效:
# create temp table my_temp as select u.id, u.first_name, u.last_name,
count(nullif(r.nice, false))-count(nullif(r.nice, true)) as rep
from pref_users u, pref_rep r
where u.vip>now() and u.id=r.id group by u.id;
SELECT 362
然后我的SQL JOIN返回太多相同的行,我找不到那里缺少的条件:
# select u.id, u.first_name, u.last_name
from pref_rep r, pref_users u, my_temp t
where r.author=u.id and u.vip>now()
and u.id=t.id and t.rep<0;
id | first_name | last_name
-------------------------+--------------------------------+----------------------------
OK400153108439 | Vladimir | Pelix
OK123283032465 | Edik | Lehtik
OK123283032465 | Edik | Lehtik
OK123283032465 | Edik | Lehtik
OK123283032465 | Edik | Lehtik
OK123283032465 | Edik | Lehtik
OK123283032465 | Edik | Lehtik
同样的问题(具有相同数据的多行)我得到的声明:
# select u.id, u.first_name, u.last_name
from pref_rep r, pref_users u
where r.author = u.id and u.vip>now()
and u.id in (select id from my_temp where rep < 0);
我想知道这里可能缺少什么条件?
答案 0 :(得分:2)
首先,我会写下你的第一个查询:
select
u.id, u.first_name, u.last_name,
sum(case
when r.nice=true then 1
when r.nice=false then -1
end) as rep
from
pref_users u inner join pref_rep r on u.id=r.id
where
u.vip>now()
group by
u.id, u.first_name, u.last_name;
(它和你的一样,但我发现它更清楚了。)
要查找负面评分的玩家,您可以使用与之前相同的查询,只需添加HAVING子句:
having
sum(case
when r.nice=true then 1
when r.nice=false then -1
end)<0
找到评级为负的玩家,一个解决方案就是:
select
s.id, s.first_name, s.last_name, s.rep
from (
select
u.id, u.first_name, u.last_name,
sum(case
when r.nice=true then 1
when r.nice=false then -1
end) as rep
from
pref_users u inner join pref_rep r on u.id=r.id
where
u.vip>now()
group by
u.id, u.first_name, u.last_name
having
sum(case
when r.nice=true then 1
when r.nice=false then -1
end)<0
) s
where
exists (select * from pref_rep p where p.author = s.id)
最终可以从内部查询中删除having子句,并且您可以在外部查询中使用此where子句:
where
rep<0
and exists (select * from pref_rep p where p.author = s.id)
答案 1 :(得分:2)
您忘了提及pref_users.id
被定义为PRIMARY KEY
- 否则您的第一个查询将无效。这也意味着id
已经编入索引。
最佳查询在很大程度上取决于典型的数据分布。
假设:
确定几个可能的候选人并且仅计算到达最终选择的人的总评级将是有效的 - 而不是计算每个用户的总和而然后只过滤少数。
SELECT *
FROM ( -- filter candidates in a subquery
SELECT *
FROM pref_users u
WHERE u.vip > now()
AND EXISTS (
SELECT 1
FROM pref_rep
WHERE author = u.id -- at least one rating given
)
AND EXISTS (
SELECT 1
FROM pref_rep
WHERE id = u.id
AND NOT nice -- at least one neg. rating received
)
) u
JOIN LATERAL ( -- calculate total only for identified candidates
SELECT sum(CASE nice WHEN true THEN 1 WHEN false THEN -1 END) AS rep
FROM pref_rep
WHERE id = u.id
) r ON r.rep < 0;
显然,除了pref_rep.author
列上的(也假设!)PRIMARY KEY
索引外,id
上还需要索引。
如果您的表很大,一些更高级的索引将支付。
首先,您似乎只对当前的VIP用户感兴趣(u.vip > now()
)。 vip
上的普通索引会有很长的路要走。或者甚至包含id
的部分多列索引并截断索引中的旧元组:
CREATE INDEX pref_users_index_name ON pref_users (vip, id)
WHERE vip > '2015-04-21 18:00';
考虑细节:
如果(且仅当)否定投票是少数,pref_rep
上的部分索引也可能支付:
CREATE INDEX pref_rep_downvote_idx ON pref_rep (id)
WHERE NOT nice;
使用EXPLAIN ANALYZE
测试性能,重复几次以排除缓存效果。