我正在實施類似於StackOverflow標籤系統的標籤系統。我在考慮存儲標籤和問題時，這種關係將直接與標籤名稱相關，或者最好創建一個字段標籤ID來將問題與標籤「鏈接」？看起來，直接鏈接到標籤名稱更容易，但它看起來不太好，主要是爲什麼使用統計和/或標籤分類（恕我直言）可能很難管理這一點。另一個問題是一個管理員決定「修復」標籤名稱。如果沒有與標籤名稱分開的標籤ID，那麼我將更改表格的密鑰...標籤系統中標籤的ID
您的想法是什麼？
感謝您的回覆。我會刪除這篇文章，因爲有另一篇文章的主題相同。我想知道爲什麼搜索和建議沒有顯示出我的結果...
如果您預見了很多標籤，並且正在使用關係數據庫，那麼使用數據庫在本地支持的ID（例如RID）只是給你更好的表現。
如果這不是一個問題：去簡單的短標籤名稱。您可以爲標籤提供長名稱，這些名稱也將在用戶界面中顯示，例如，在創建新標籤時詢問用戶。你更有可能不得不編輯長名字，這些名字都沒有直接引用，所以這不是問題。
另外，如果您使用的是關係數據庫，使用簡單的查詢來更改標籤名稱及其所有引用可能不是很困難，但它可能只是一個稍微昂貴的操作，但它可能不是要經常完成，你需要爲它進行優化。並且考慮到你可能有重複的標籤，你也想合併，所以你可能希望能夠做到這一點。
你在你的問題中的最後一句似乎回答它。假設標籤存儲在一個標籤表中，我總是會有一個ID列（int或GUID）和標籤名稱的varchar/string列。將一些其他實體與一個或多個標籤相關聯的多對多（聯結表）將具有包含該ID的「其他實體」和標籤的ID的兩列。 然後輕鬆編輯標籤（例如糾正拼寫錯誤）而無需觸摸該鍵。在使用包含與聯結表聯接的查詢時，您應該獲得更好的性能，這也意味着您可以更好地規範化數據。
請記住，「the key, the whole key and nothing but the key, so help me codd」！ :)
要求用戶在創建標籤時同時提供短版本和長版本只會導致混淆。最好堅持使用標籤名稱或人造鑰匙，就像您建議的那樣。 – BigJump 2009-02-14 16:12:00
我同意這可能會導致混淆 - 這取決於網站和麪向的用戶。這可以是可選的，但僅在創建標籤時才需要完成，所以爲了用戶友好名稱的好處，這可能是值得的。 – 2009-02-14 16:16:44