使用“标签”的应用程序数据库设计答案

【问题标题】：Database design for apps using "hashtags"使用“标签”的应用程序数据库设计
【发布时间】：2023-03-20 08:49:02
【问题描述】：

这里有数据库设计问题。

假设我们有一个 web 应用程序或使用主题标签的 20-40 字笔记。存储用户主题标签的最佳方式是什么。

例如，如果用户输入。 "I like to have #lunch at #sizzler" 我们会将句子存储为文本，我们可以将主题标签存储为 JSON、逗号分隔列表或其他机制。

另外值得指出的是，标签需要是可搜索的，比如有多少人在hash taglunch等。

关于这件事的建议会很好，当谈到在 mysql 中存储可变大小的输入时，我总是有点难过。每个笔记可以有无限数量的主题标签，存储它们的最佳方式是什么？

【问题讨论】：

不是为了打败马，但是当重新考虑这一点时，我注意到你没有在问题中专门要求 mysql（甚至提到 csv 和 json ......），是否可以标记这个通常作为“数据库”，因为它可能会打开有趣的替代 nosql 解决方案或其他东西？ ....（我很好奇将 nosql 与关系解决方案进行比较并回到这里，这就是我问的原因:)）

标签： mysql normalization hashtag

【解决方案1】：

我建议在消息和标签之间使用典型的多对多关系。

这意味着您需要 3 张桌子。

Messages（列Id、UserId 和Content）
Tags（列 Id 和 TagName）
TagMessageRelations（列：MessageId 和 TagId - 在消息和标签之间建立连接 - 通过指向 Messages.Id / Tags.Id 的外键）

这样您就不会多次存储标签，而只会创建与消息的新关系（当然，如果该标签已经存在于标签表中）。

这样就可以了

轻松计算标签数量 (SELECT COUNT(*) FROM Tags)
每个标签只保存一次，搜索标签可以轻松索引
或计算每个用户使用某个标签的次数 - 例如：

SELECT COUNT(*) FROM Tags INNER JOIN TagMessageRelations ON Tags.Id = TagMessageRelations.TagId INNER JOIN Messages ON TagMessageRelations.MessageId = Messages.Id GROUP BY Messages.UserId

【讨论】：

太棒了，这基本上就是我的想法。标签表中的标签是唯一的吗？
是的，就是这个想法，它们在 tags-table 中是唯一的，但在 tagMessagesRelation-table 中有多个关系。
谢谢，很高兴我能帮上忙； ps：谢谢提醒，我迟到了一些杀灵的动作：D
为什么不使用标签名作为id？并可能删除一个表（让所有标签都使用不同的选择）。真的慢很多吗？无论如何，最后都会有名称到 id 的转换。最后可能会有所有标签的内存缓存字典。
@StefanCebulak 你可以这样做。 TLDR；我很确定额外的数据量（INT 列）对其他列来说是微不足道的，应该会在性能上有所回报。 Speedwise，我想您只有在数据库中有大量数据时才会注意到。我自己没有对此进行测试，但似乎有一些证据表明加入 ints 比加入 varchars 更有效（例如）以下链接是关于 sql server 的：sqlinthewild.co.za/index.php/2011/02/15/…