所以我正在为一个个人项目建立一个数据库，只是为了让我的脚更容易使用PostgreSQL以及可以使用PostgreSQL数据库的某些语言和应用程序。
我已经意识到使用数组并不一定是合规的（数组不是原子的，对吗？）和1NF。所以我的问题是：这种方式是否缺乏效率或数据安全性？我应该尽早学习不使用数组吗？
答案 0 :(得分：16)
标题的简短回答：否
答案稍长：
您应该学会在适当的时候使用数组。数组设计本身并不坏，它们像字符变化字段一样原子（字符数组，没有？），它们的存在使我们的生活更轻松，数据库更快更轻。考虑可移植性存在一些问题（大多数数据库系统不支持数组，或者以与Postgres不同的方式执行此操作）
示例：
您有一个包含帖子和标签的博客，每个帖子可能包含0个或更多标签。首先想到的是创建一个包含两列postid和tagid的不同表，并在该表中分配标记。
如果我们需要使用tagid搜索帖子，那么额外的表格是必要的（当然有适当的索引）。
但是如果我们只希望标签信息显示为帖子的额外信息，那么我们可以轻松地在帖子表中添加整数数组列并从那里提取信息。这仍然可以使用额外的表来完成，但是使用数组会减小数据库的大小（不需要额外的表或额外的行）并通过让我们加入少一个表来执行我们的选择查询来简化查询，并且似乎更容易理解通过人眼（最后一部分在旁观者的眼中，但我想我在这里说多数）。如果我们的标签是预加载的，那么甚至不需要一个连接。
这个例子可能很差，但这是我想到的第一个。
<强>结论：
阵列不是必需的。如果你使用它们，它们可能是有害的。您可以在没有它们的情况下生活，拥有一个优秀，快速和优化的数据当您考虑可移植性（例如，重写您的系统以使用其他数据库）时，您不能使用数组。
如果你确定你会坚持使用Postgres，那么你可以安全地使用你认为合适的数组。它们存在是有原因的，既不是糟糕的设计也不是不合规的。当您在正确的位置使用它们时，它们可以帮助您简化数据库结构和代码，以及空间和速度优化。就是这样。
答案 1 :(得分：3)
数组是否是原子的取决于你感兴趣的内容。如果你通常想要整个数组，那么它就是原子的。如果您对单个元素更感兴趣，那么它将被用作结构。文本字段基本上是字符列表。但是，我们通常对整个字符串感兴趣。
现在 - 从实用的角度来看，许多框架和ORM都不会自动解包PostgreSQL的数组类型。此外，如果要将数据库移植到例如MySQL然后你
同样，外键约束不能添加到数组中（除非它在9.3中 - 似乎并非如此）。
答案 2 :(得分：0)
我相信在您使用类似数组的数据并希望利用SQL的强大功能进行有效查询和分析的情况下，数组是一种有用且适当的设计。我已经开始定期使用PostgreSQL数组用于数据科学目的，并在PostGIS中开始使用边缘情况作为示例。
除了上面提到的充分解释的挑战之外，我发现了让第三方客户端应用能够以我期望的方式处理阵列字段的最大问题。例如，在Tableau和QGIS中，数组被视为字符串，因此数组操作不可用。
数组是SQL标准中的第一类数据类型，通常允许更简单的模式和更高效的查询。通常，数组是一种很好的数据类型。如果您的实现是自包含的，并且不需要依赖第三方工具而没有API或其他可以处理不兼容性的中间件，那么请使用数组字段。
但是，如果您与直接查询数据库的第三方软件接口，并且数组用于生成查询，那么我会避免它们支持更简单的查找表和其他传统的关系方法。
答案 3 :(得分：-1)
简短回答：是的，这是糟糕的设计。使用数组将保证您的设计不是1NF，因为1NF必须没有重复值。正确的设计是明确的：为数组的值创建另一个表，并在需要时加入。
在某些有限的情况下，阵列可能是工作的正确工具，但我仍会努力避免它们。它们是最后的特色。
阵列最大的问题是它们是一个拐杖。你已经了解它们并且想要使用它们，因为它们对你很熟悉。但它们并不像您期望的那样工作，它们只会让您推迟对SQL和关系数据库的真正理解。你最好等到你被迫使用它们，而不是学习它们并寻找依赖它们的机会。