數據庫中的設計標記模組
我有一個數據庫系統，我們想在其中定義許多表的標籤。例如，我有影片、照片……我們希望將它們標記為不同的實體。標籤可以是任何東西。通過標記，我的意思是我們希望允許前端使用者為這些實體（關鍵字）定義標記，類似於 Facebook 標記。我們想讓它對以後可能出現在系統中的任何實體都可擴展，並且我們也希望它是可標記的。最初，我們認為這可能是我們希望它可標記的每個實體與數據庫中的每個標記實體之間的多對多關係。例如，如果我們想在照片中標記使用者，那麼可以在一張照片中標記許多使用者，並且許多照片中可能標記了同一個使用者。但是這種設計使事情變得複雜，因為我們需要在所有可標記實體和我們想要添加標籤的對象之間建立多對多的關係。所以我們將在使用者和照片、使用者和影片之間建立多對多的關係，…。這僅適用於使用者實體，如果我們有其他實體，我們也會這樣做，所以它很複雜且不可擴展。所以我們試圖加強這一點，我們提出了以下想法。
我們將有一個完全沒有關係的表，它不連接到任何其他表，該表將包含以下內容，標籤 ID，標籤值，實體對象 ID（例如：使用者 ID），實體對像類型（例如: 使用者）、可標記對象 ID（例如：照片 ID）、可標記對像類型（例如：照片）。我們將為實體對象 id 列和實體對像類型添加索引，也為可標記對象 id 和可標記對像類型添加索引以加快搜尋過程。
但我想知道是否有任何模式可以解決這個問題，以及上述兩種解決方案中哪一種更好。
您在第二段中描述的內容聽起來像實體屬性值模式。
這是處理您正在談論的數據類型的已知模式。當您需要能夠擴展時，從數據中驅動類型，並允許您在增長時開始跟踪新類型。它允許您保持靈活和敏捷，並且在您的數據庫設計和架構中更加寬容和通用。
即使在關係數據庫中，這種模式也有效，但要獲得良好的性能確實需要做更多的工作，並且可能會讓您頭疼，具體取決於行數、插入次數以及查詢頻率。這個SO 問題在以 20 票列出的第一個答案中很好地談論了一些陷阱。我已經看到這個模型執行良好，特別是在新類型和實體確實出現的環境中，我們希望讓它更多地由應用程序驅動或使用者驅動，但我們在該模型中比傳統關係數據庫更經常地與性能作鬥爭模型，但我們需要靈活性，我們讓它發揮作用。一定要看看那個 SO 問題，並對 EAV 和您使用的任何 DBMS 進行更多研究，以從其他嘗試過相同方法的人那裡找到範例。