在我看来,PostgreSQL数组数据类型的功能与标准的一对多和多对多关系重叠很多。
例如,一个名为users的表可能有一个名为“favorite_colors”的数组字段,或者可能有一个名为“favorite_colors”的单独表和一个“users”和“favorite_colors”之间的连接表。
在什么情况下使用数组数据类型OK而不是完整的连接?
答案 0 :(得分:20)
不应使用类似于关系的数组。它应该包含与一行非常紧密相关的索引值。例如,如果你有一张足球比赛结果的桌子,那么你就不需要做了
id team1 team2 goals1 goals2
但会做
id team[2] goals[2]
因为在这个例子中,大多数人还会考虑将其归一化为两个表是愚蠢的。
总而言之,我会在你不想建立关系的情况下使用它,而在其他地方你会添加像field1 field2 field3
这样的字段。
答案 1 :(得分:4)
一个非常方便的用例是标记:
CREATE TABLE posts (
title TEXT,
tags TEXT[]
);
-- Select all posts with tag 'kitty'
SELECT * FROM posts WHERE tags @> '{kitty}';
答案 2 :(得分:2)
The Postgresql documentation gives good examples:
CREATE TABLE sal_emp (
name text,
pay_by_quarter integer[],
schedule text[][]
);
上面的命令将创建一个名为sal_emp的表,其列为 type text(name),一个整数类型的一维数组 (pay_by_quarter),表示员工按季度划分的工资, 和一个二维的文本数组(schedule),代表了 员工的每周安排。
或者,如果您愿意:
CREATE TABLE tictactoe (
squares integer[3][3] );
答案 3 :(得分:0)
我完全同意@marc。当您完全确定不需要在数组中的项目与任何其他表之间创建任何关系时,将使用数组。应该用于一对多关系的紧密结合。
一个典型的例子是创建一个选择题系统。由于其他问题不需要知道某个问题的选项,因此这些选项可以存储在数组中。
例如
CREATE TABLE Question (
id integer PRIMARY KEY,
question TEXT,
options VARCHAR(255)[],
answer VARCHAR(255)
)
这比创建question_options
表并通过联接获取选项要好得多。
答案 4 :(得分:0)
如果我要存储某种相似类型的数据集,而这些数据没有任何其他属性。
我更喜欢使用数组。
一个例子是:
存储用户的联系电话
因此,当我们要存储联系电话时,在这种情况下通常是主电话号码和备用电话号码
我更喜欢使用数组。
CREATE TABLE students (
name text,
contacts varchar ARRAY -- or varchar[]
);
但是,如果这些数据具有其他属性,请说存储卡。 卡上可以有有效期和其他详细信息。
另外,将标签存储为数组不是一个好主意。标签可以与多个帖子关联。
在这种情况下不要使用数组。