标记博客文章时我真的应该使用关系表吗？

Question

在试图弄清楚如何使用单个 sql 语句 here 标记博客文章时，我想到了以下想法：使用通过 id 引用标签的关系表 tag2post 如下所示：

tags
+-------+-----------+
| tagid | tag       |
+-------+-----------+
|     1 | news      | 
|     2 | top-story | 
+-------+-----------+

tag2post
+----+--------+-------+
| id | postid | tagid |     
+----+--------+-------+
|  0 |    322 |     1 |
+----+--------+-------+

为什么不只使用下面的模型，你索引标签本身如下？认为标签永远不会重命名，而是添加和删除，这可能是有道理的，对吧？你觉得呢？

tag2post
+----+--------+-------+
| id | postid | tag   |     
+----+--------+-------+
|  1 |    322 | sun   |
+----+--------+-------+
|  2 |    322 | moon  |
+----+--------+-------+
|  3 |   4443 | sun   |
+----+--------+-------+
|  4 |   2567 | love  |
+----+--------+-------+

PS：我保留了一个id，我是为了方便显示最后添加的n个标签...

Answer 1

根据您的应用程序，去规范化的方法可能没问题。 由于搜索大量 VARCHAR 数据，您可能会发现它会导致性能下降。

搜索标记为“sun*”的内容时（例如 sun、sunny、sunrise） 你不需要加入。但是，您需要对更大的 VARCHAR 数据集进行类似比较。正确的索引可能会缓解这个问题，但只有测试才能告诉您哪种方法对您的数据集更快。

您还可以选择添加预联接规范化表的 VIEW。这为您提供了更简单的查询，同时仍然允许您拥有高度规范化的数据。

我的建议是使用规范化结构（并添加非规范化视图以方便使用），直到您遇到非规范化数据架构修复的问题。

Answer 2

与包含 ID 的关系表相比，您的提议的真正优势在哪里？

从技术上讲，它们解决了同样的问题，但您提出的解决方案是以一种冗余的、非规范化的方式来解决的，这似乎只是为了满足能够直接从关系表中读取数据的本能冲动。

数据库服务器非常擅长连接表，如果连接是在一个带有索引的 INT 字段上，则更是如此。当您将另一个表（例如：INT id, VARCHAR(50) TagName）加入查询时，我认为您不会面临毁灭性的性能问题。

但是您失去了轻松重命名标签的能力（即使您不打算这样做），并且您不必要地用冗余数据膨胀您的关系表。随着时间的推移，这可能会比标准化解决方案花费更多的性能。

Answer 3

我也在考虑这个。想要数据库中的标签列表，只需从 tag2post 中选择不同的标签。有人告诉我，由于我想针对 select 语句进行优化，所以最好使用整数键，因为它比使用字符串快得多。

Answer 4

它可以工作，但它没有被规范化，因为标签中有冗余。您也无法使用“相同”标签来标记帖子以外的内容。对于小N，优化无关紧要，你用它跑也没问题。

实际上，您的索引会更大（假设您要对标签进行索引以进行搜索，您现在正在索引重复项和索引字符串）。在规范化版本中，tags 表上的索引会更小，不会有重复，tagid 上的 tag2post 表上的索引会更小。此外，固定大小的 int 列对于索引非常有效，您还可以根据您的集群选择避免一些碎片。

我知道您说不重命名，但总的来说，在这两种情况下，您可能仍需要考虑重命名（甚至删除）标签的语义 - 是否需要更改所有条目，或者标签是否以某种方式拆分。因为这是最坏情况下事务中的批处理操作（所有 tag2post 都必须重命名），所以从设计的角度来看，我并没有真正将其归类为重要。

Answer 5

这听起来不错当他更改它时，在您的数据库中。但是在这种情况下，标签名称本身不会改变，所以我看到的唯一潜在缺点是文本索引可能比数字索引搜索要慢一些。