2013-03-07 89 views
2

我有三个表:聚合函数连接表

CREATE TABLE foo (
    id bigint PRIMARY KEY, 
    name text NOT NULL 
); 

CREATE TABLE foo_bar (
    id bigint PRIMARY KEY, 
    foo_id bigint NOT NULL 
); 

CREATE TABLE tag (
    name text NOT NULL, 
    target_id bigint NOT NULL, 
    PRIMARY KEY (name, target_id) 
); 

我试图创建一个视图,这样我得到的所有表foo的领域,项目的foo_bar其中foo.id = foo_bar.foo_id计数,以及所有标签的文本数组,其中foo.id = tag.target_id。如果我们有:

INSERT INTO foo VALUES (1, 'one'); 
INSERT INTO foo VALUES (2, 'two'); 
INSERT INTO foo_bar VALUES (1, 1); 
INSERT INTO foo_bar VALUES (2, 1); 
INSERT INTO foo_bar VALUES (3, 2); 
INSERT INTO foo_bar VALUES (4, 1); 
INSERT INTO foo_bar VALUES (5, 2); 
INSERT INTO tag VALUES ('a', 1); 
INSERT INTO tag VALUES ('b', 1); 
INSERT INTO tag VALUES ('c', 2); 

结果应该返回:

foo.id | foo.name  | count  | array_agg 
-------------------------------------------------- 
1   | one   | 3   | {a, b} 
2         | two          | 2           | {c} 

这是我到目前为止有:

SELECT DISTINCT f.id, f.name, COUNT(b.id), array_agg(t.name) 
FROM foo AS f, foo_bar AS b, tag AS t 
WHERE f.id = t.target_id AND f.id = b.foo_id 
GROUP BY f.id, b.id; 

这是我得到的结果(注意count是不正确的):

foo.id | foo.name  | count  | array_agg 
-------------------------------------------------- 
1   | one   | 2   | {a, b} 
2         | two          | 1           | {c} 

count始终是标记的计数,而不是不同的foo_bar值的计数。我试过重新排序/修改GROUP BYSELECT子句,它们会返回不同的结果,但不是我正在查找的结果。我认为我在array_agg()函数中遇到了问题,但我不确定是否如此,或者如何解决它。

回答

7
SELECT f.id, f.name, b.fb_ct, t.tag_names 
FROM foo f 
LEFT JOIN (
    SELECT foo_id AS id, count(*) AS fb_ct 
    FROM foo_bar 
    GROUP BY 1 
    ) b USING (id) 
LEFT JOIN (
    SELECT target_id AS id, array_agg(name) AS tag_names 
    FROM tag 
    GROUP BY 1 
    ) t USING (id) 
ORDER BY f.id; 

产生所需的结果。

  • 用明确的ANSI JOIN语法重写。使它更容易阅读和理解(和调试)。

  • 通过加入多个1:n相关表格,行之间会相互乘以产生Cartesian product - 这是非常昂贵的废话。这是代理人无意识的CROSS JOIN。阅读详细说明在此密切相关的答案:
    Two SQL LEFT JOINS produce incorrect result

  • 为了避免这种情况,请加入最多一个n -table到1 - 表您汇总(GROUP BY)前。您可以汇总两次,但在这里汇总所有n-表中各个之前的您可以将它们加入到1表中。

  • 与您原来的相反(隐含INNER JOIN)。我使用LEFT JOIN以避免在foo_bartag中没有匹配行的foo的行丢失。

  • 一旦从查询中删除意外CROSS JOIN,你有没有必要添加任何DISTINCT更多 - 假设foo.id是独一无二的,即使你没有澄清。

+0

感谢您的详细解释! – Bill 2013-03-07 01:41:42

+0

@ Bill:这应该是非常快的,即使是一百万行。但为什么猜测你是否可以测试?用100k行填充你的表,并用'EXPLAIN ANALYZE'运行查询。你可以找到一个例子[如何使用'generate_series()'轻松地在这里构建一个测试](http://stackoverflow.com/questions/15169410/how-do-you-do-date-math-that-ignores-the - 年/ 15179731#15179731)。 SO上还有更多。另外考虑我的答案的补充位。 – 2013-03-07 01:43:16

+0

感谢球场,这就是我的兴趣所在。我一定会测试,但目前没有生产硬件,我的虚拟机测试不会产生有用的结果。我只需要知道这是否是一个明显可怕的想法,我应该立即纠正。再次感谢! – Bill 2013-03-07 01:48:32