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