将数组存储为字段值或将数组值存储为记录是个好主意吗？

Question

在我的应用程序中，我有带有描述性预定义标签的“文章”（类似于帖子/推文/文章）：即“困难”、“简单”、“红色”、“蓝色”、“业务”等等

这些可用标签存储在一个表中，称为“标签”，其中包含所有可用标签。

每篇文章都可以使用多个标签进行标记，可通过自定义管理界面进行编辑。

将每个实体的标签简单地捆绑到每个标签的 ID 的字符串化数组中并将其与文章记录一起存储在我的“文章”表中可能很诱人：

id | title | author | tags
---+-------+--------+-------------
1  | title | TG     | "[1,4,7,12]"

尽管出于多种原因，我确信这是一个坏主意，但是否有合理的理由来执行上述操作？

Answer 1

我认为您应该阅读Database normalization 并自行决定。简而言之，您的提案存在许多问题，但您可以决定接受这些问题。

最明显的是：

1. 如果在第 (1) 行添加了一个额外的标签怎么办？您是否必须先解析，检查它是否已经存在，然后将行更新为tags.append(newTag)。
2. 仍然删除标签更糟糕？搜索标签，存在，重新创建标签。
3. 如果标签要更改名称怎么办？也许需要一些审核过程？
4. 更糟糕的是，如果不同的人以不同的方式指定标签名称会怎样 - 这很难合理化。
5. 如果要根据标签查询数据怎么办？您的查询变得比需要的复杂得多。
6. 演示：客户端必须解析标签才能使用它。分隔符字段呢？改变这一点，所有客户都必须改变。

简而言之，所有这些操作都变得更加困难和繁琐。规范化旨在克服这些问题。 IMO，做你所说的事情的唯一原因可能是你一次性捕获数据，而且它只是信息性的——也就是说，对用户有意义，但对系统本身没有意义。这有点像说它可能最好避免（再次，IMO）。

Answer 2

在我看来，您似乎想要一个单独的表来存储标签并保存一个外键，该外键将标签记录与文章表中的父记录相关联（这被称为“规范化”数据库结构） .

按照您的建议将标签塞进一个字段现在似乎很有意义，但随着应用程序规模的增长或数据量增长了很多。

考虑到创建另一个表并设置关系以链接两个表之间的键以保持引用完整性是多么简单，我想说几乎没有理由按照您的建议进行操作。

Answer 3

我完全同意它可以是个好主意。我强烈主张将数据库中的标签存储为单个分隔的字符串列表。

但是：我同意的原因是我喜欢使用 Azure 搜索 API 来索引这些类型的数据，因此基于标签进行查找的查询不是通过 SQL 完成的。 （不需要使用 Azure 搜索 API 服务，但根据我的经验，使用数据库外部的搜索索引可以获得更好的性能和可扩展性。）

如果您的主要查询语言是 SQL（基于关系的查询） 那么你最好创建一个子表，每个子表都有一行 标记，否则当您的查询必须执行时，您将受到性能影响 对每个值执行逻辑以将其拆分以进行分析。

标签是我们用来绕过关系数据或层次映射的概念，因此为了获得最佳性能，不要尝试使用这些关系概念来查询标签。它通常最好在 NoSQL 数据存储中实现，因为它们不会尝试使用数据库来处理搜索查询。

我鼓励您将数据存储为分隔字符串，并使用外部索引服务来提供对数据的搜索和洞察。这是 CRUD 数据访问性能尝试管理数据和索引以优化搜索之间的良好折衷。当然，您可以优化数据库和搜索查询以使其在 SQL 中工作，但需要努力才能使其正确。

一旦您的用户群达到大量数量，并且您需要在不影响更新性能的情况下支持多个并发搜索，您会发现外部索引现在是一项非常棒的投资，可以在以后节省您的时间和资源。