用于标记多个来源的数据库设计（MySQL）

Question

我正在做一个项目，我有以下（编辑的）表结构：（MySQL）

Blog
    id
    title
    description

Episode
    id
    title
    description

Tag
    id 
    text 

这个想法是标签可以应用于任何博客或剧集（以及其他类型的来源），如果标签表中不存在新标签，则用户可以创建新标签。

标签的目的是让用户能够搜索网站，结果将搜索网站上所有类型的材料。 此外，在每篇博客文章/剧集描述的底部，都会有该项目的标签列表。

我对搜索机制考虑了太多，但我想它在 OR 和 AND 搜索之间会很灵活，如果这对选择有任何影响，并且可能允许用户过滤特定类型来源的结果。

最初我打算创建多个标签映射表：

BlogTag
    id
    tag_id
    blog_id

EpisodeTag
    id
    episode_id
    tag_id

但现在我想知道我是否会更好：

TaggedStuff
    id
    source_type
    source_id
    tag_id

其中 source_type 将是 integer ，它与我未包含在上述结构中的情节、博客或其他类型有关，并且 source_id 将是该特定表中的引用。

我只是想知道最佳结构是什么，第一选择还是第二选择？

Answer 1

使用结构 2 的最大损失是引用完整性的损失。 如果您可以对此说“随便”，那么使用这种结构 go 可能会更容易。

当我说结构 2 时，我的意思是：

标记的东西

id source_type source_id tag_id

Answer 2

在一个干净的（学术）设计中，您经常会看到拥有一个用于Blog和Episode的超类型Resource （或类似的东西）以及它自己的表。 标签的另一个表。 由于Tag和Resource之间是 N:M 关系，因此它们之间有一个额外的映射表。

因此，在这样的设计中，您可以通过与它们的泛化关系将标记实体与您的资源相关联。

之后，您可以将一般属性放到泛化中。 （即标题、描述）您可以将属性添加到Tag和Resource之间的关系中，例如计数器使用特定标签标记特定资源的频率。 或者一个标签的使用频率和和和（比如你在stackoverflow上看到的东西在右上角）

Answer 3

如果我理解正确，重点是优化搜索机制......所以制作某种 index_table 并削弱那里的数据是有意义的......

我的意思是这样的：Url、Type、Title、Search_Field 等。其中 Url 是文章或剧集的路径，Type（文章|剧集），名称（用户将看到的内容），Search_Field（标签列表，其他重要的搜索数据）

这就是为什么这两种变体都很好）））