數據庫設計用於標記多個源（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的）

回答

相關問題