有没有比在每一行返回“一个”值更有效的方法来建立一对多关系？答案

【问题标题】：Is there a more efficient way to do a one-to-many relationship than having the "one" value in every row returned?有没有比在每一行返回“一个”值更有效的方法来建立一对多关系？
【发布时间】：2016-09-16 03:17:32
【问题描述】：

我有一个非常基本的一对多关系。有“节点”，每个节点都涉及多个“选项”。我正在做一个相当简单的连接，我的结果是这样的：

           content        | optionid |     content      
--------------------------+----------+------------------
 This is the node content |        1 | This is option 1
 This is the node content |        2 | This is option 2

但是，因为它是一对多的，所以每一行都有相同的节点内容：This is the node content。当我只需要一次时，每行返回相同的值似乎是多余的。有没有更好的办法？

【问题讨论】：

您可以使用很多不同的aggregate functions。例如，如果 optionid 是唯一的，json(b)_object_agg 可以很好地为您工作。
冗余是否对您造成了伤害？例如，它会减慢您的速度吗？
@Sevanteri 谢谢你告诉我这个！ jsonb_object_agg 正是我想要的。如果您将其发布为答案，我会接受。

标签： database postgresql join database-design one-to-many

【解决方案1】：

jsonb_object_agg aggregate function 这似乎是一个不错的选择。

SELECT
    n.content,
    jsonb_object_agg(o.optionid, o.content)
FROM node n
JOIN option o ON (
    -- what ever are the conditions
)
GROUP BY n.content;

【讨论】：

我认为 json（文本格式）优于 jsonb（二进制格式），但是很好的答案。
视情况而定。如果您总是要选择整个 JSON，那么是的，使用 JSON 而不是 JSONB 可能会更好。是的，在这种情况下，它实际上可能会更好。

【解决方案2】：

嗯，这就是关系数据库的工作方式——你必须做出妥协。

如果您认为此查询在应用服务器和数据库之间产生了太大的数据流，您可以将其拆分为两个查询。单独加载content，然后再加载options，避免冗余。这也可能具有性能优势（更少的内存、没有 JOIN 等）。

另一方面，由于正在运行单独的查询，这会产生延迟。特别是在循环查询中，这可能会明显变慢。所以，一切都是为了妥协。

【讨论】：