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

我工作的一个项目，我有以下（编辑）的表结构：（MySQL的）数据库设计用于标记多个源（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将是一个整数，关系到能否它是一个Episode，Blog或其他一些我没有包含在上述结构中的类型，并且source_id将作为该特定表中的参考。

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

来源

2011-06-08 Andrew Johns

结构2损失最大的是referential integrity。如果你可以说“无论如何”，这个结构可能会更容易。

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

TaggedStuff

id 
source_type 
source_id 
tag_id

来源

2011-06-08 13:10:52

如果我理解正确的话，关键是要优化搜索机制... 因此具有意义使某种index_table和挫伤数据那里...

我的意思是像这样的smth： Url，Type，Title， Search_Field等。其中URL是路径文章或插曲，类型（文章|插曲），姓名（用户看到的），Search_Field（标签列表，其他搜索重要的数据）

这就是为什么这两个变种是相当不错的）））

来源

2011-06-08 13:11:04

在一个干净的（学术）设计，你会经常看到有一个超类型Resource（或类似的）Blog和Episode与它自己的表。另一个标签表。由于它是Tag和Resource之间的N：M关系，所以它们之间有一个额外的映射表。

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

simplified ER-Diagram

之后，你可以把一般属性的概括。（即标题，说明）您可以将Tag和Resource之间的关系的属性添加到计数器中，如计数器使用特定标签标记特定资源的频率。或者标签的使用频率和和（和你喜欢的东西在这里右上角的stackoverflow中看到）

来源

2011-06-08 13:25:44

我有一种感觉，这是我走的路。以此为基础开始，因为它是“正确的”标准化设计，那么如果/当涉及到提高系统效率时，我可以开始寻找加快速度的方法。 – 2011-06-08 16:53:15

是的，正如我在别处的另一个答案中写的，有三个主要概念如何为泛化创建表。但最常见的是拥有泛型类型和所有子类型的表格。它有许多优点，但也有一些缺点，比如更多的JOIN（可能会减慢速度），当你仅仅从泛化中知道主键时，获得整个实体会有点棘手。（ - >我必须加入什么表格？Episode或Blog？）另一种方式很容易，但这就是你经常做的事情。 – 2011-06-08 17:07:11

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

回答

相关问题