在数据库中存储一对多关系 - 数组还是一对多关系？

Question

当我们在数据库中存储一对多关联时，这是一种更好的方法。 One - 许多映射在表中或将许多部分存储为数组。我特定于postgres数据库（约束）

例如：如果我们按如下方式定义关系

a   b
1 - 2
1 - 3
1 - 6
2 - 3 
2 - 4
3 - 5
3 - 6

这里，一部分是a，许多部分是b（主键是a，b）

同样的东西可以存储为数组（类似于邻接列表）。

1 - {2,3,6}
2 - {3,4}
3 - {5,6}

哪一个更有效率。我可能不得不对此进行一些操作，例如传递闭包等，图形可能非常大。

以上的实际示例可能类似于特定配置文件的连接（LinkedIn连接）或任何社交图形场景

Answer 1

在你的例子中，关系是多对多，而不是一对多。多个a记录可以与一个b相关联，多个b记录可以与一个a相关联。因此，正确的规范化形式是join table。

假设，想象一下这个数据库关系代表一个简介＆＃34;喜欢＆＃34;社交媒体背景下的另一个档案。在这种情况下，您可能希望存储其他信息; ＆＃34;喜欢＆＃34;的时间戳。已启动，配置文件耸耸肩/喜欢/喜欢其他配置文件的程度等。然后很明显，在阵列实现中无处存储此附加数据。你需要一个联接表，以便每个＆＃34;喜欢＆＃34;可以有自己的元数据。

这是我建议的结构：

PK   A   B
100  1 - 2
200  1 - 3
300  1 - 6
400  2 - 3 
500  2 - 4
600  3 - 5
700  3 - 6

PK是自动生成的PK，希望来自序列，A, B受唯一索引的约束。这种结构是最终放弃A, B上唯一索引的未来证据，这是我偶尔必须处理的头痛。