Hashtags 的最佳 JPA 实体模型

Question

我需要在我的应用程序中为标签设计一个 JPA 实体模型，类似于 Instagram、twitter 和 Stack Overflow。我的应用程序。以下是我们的应用程序使用的架构特定点

• Hashtag 应该属于一个问题
• Hashtag 是用户特定的。
• 每个用户都可以使用相同的主题标签标记他们的问题

目前，我有上述模式的两个 JPA 模型

适用于两种型号的通用表

表：问题

列：id、问题、描述等，

表：用户

列：id、name、role、group等，

模型 1

表：question_hash_tags

列：id、question_id、user_id、hashtag_text

型号 2

表：主题标签

列：id、hastag_text

表：user_hashtags

列：user_id、hashtag_id、question_id

即使用户之间的主题标签相同，模型 1 也会有每一行。

模型 2 将具有唯一的主题标签行，并且使用 user_hashtags 跨用户引用。

我期待超越这两者的更好的标准模型。

注意：问题可根据主题标签和用户进行搜索

Answer 1

我们这里有三个“东西”：用户、问题和标签。我会在您的示例中避免使用模型 #1，主要是因为它不灵活。当产品负责人后来决定向标签添加描述时会发生什么？如果下周产品负责人希望用户只从现有池中选择标签，会发生什么？虽然您的领域需求不完整且不明确，但更灵活的解决方案允许在您的模型之上实现未来的功能，而无需进行重大重构。话虽如此，我肯定会认为 Hashtag 是它自己的独立实体。

在您的第二个模型中，USER_HASHTAGS 表中表示的第三级关系似乎假定用户和问题之间存在可选的多对多关系。如果您的域确实需要许多用户可以编写相同的问题，我认为模型 #2 将满足您的需求。更有可能的是，您的要求可能明确限制多个用户创作单个特定问题的能力。如果是这样，模型中应包含此类约束。另外，如果用户决定用 5 个不同的标签标记一个问题，那么用户和问题之间的一对多关系将在您的 user_hashtags 表中为每个标签断言 5 次。显示由用户创作的问题的简单查询将涉及使用 DISTINCT，它应该立即引起有关设计的警钟。

假设用户和问题之间存在一对多关系，我会从“USER_HASHTAGS”表中删除 USER_ID，而是将 USER_ID 作为外键放入 QUESTIONS 表中。然后将您的 USER_HASHTAGS 表重命名为 QUESTION_HASHTAGS。这使得它既简单又高效，因为现在您可以简单地查询单个表以获取由特定 USER_ID 创作的问题，而无需加入和添加数据库需要使用 DISTINCT 过滤的不知道有多少重复项。现在还支持用户选择不为其问题包含主题标签（无空白外键）的可能性。

笔记：

有许多因素会影响数据库的物理设计——不仅是“选择”访问模式，甚至可能是每个的相对频率。数据库写入与读取之间的比率、可以更新的内容以及与其他更新相关的频率等也会影响您最终构建表的方式。因此，没有“确定性”答案，只是基于一些假设和问题中提供的有限信息的答案。