也許我正在討論這個錯誤，但是我正在爲我的一個項目的數據庫設計工作。用於參照完整性的單列/僅主鍵表？
我有一個分類列的實體，將實體分組爲用戶的便利類別。這些分類是預定義的，用戶不可更改（至少這是當前的設計）。
我試圖決定是否應該有一個'EntityClassification'表，其中包含一個'Id'列作爲主鍵沒有其他信息，以便在Entity：Classification - > EntityClassification之間強制關係：ID。
我不打算在EntityClassification中擁有一個名稱/描述列，因爲我目前的想法是，我需要支持這些預定義名稱的本地化，這將使用靜態字符串表來完成，例如下載到資源文件客戶基於他們的國家/語言。真的沒有任何其他數據與我想要的EntityClassfication相關聯，並且表似乎可能是過度殺傷性的？
對於這類問題，這是常見/推薦的做法嗎？我們正在使用SQL Server 2008，並且沒有針對數據庫的枚舉數據類型，這似乎確實是我想要實現的。
您只是想確保Entity:Classification中的值僅限於您的預定列表嗎？如果是這樣的話check constraint可能是你需要的。
這樣的約束並不像外鍵那麼靈活：爲了改變檢查值我們必須刪除並重新創建約束，但是接下來你會說沒有計劃改變這些值，所以這應該不重要。
你應該有名稱和描述的表格，不僅用於最終用戶顯示，而且還有內部文檔，因此當用戶說'我的基於這種分類的查詢不起作用！'時未來僱用的人會知道他們在談論哪個ID。
對不起，如果我沒有說清楚。分類是預定義的數字有預定義的意義。 1總是等於X組。2總是等於Y組。X組或Y組可能會成爲德語中的Gruppe X，例如我正在計劃客戶端下載一個單獨的字符串resx以及它們的語言/國家特定字符串。 Silverlight將具有含義並向用戶顯示相應的內容。他們永遠不會看到數字，並將所有字符串放在數據庫中供開發人員看起來似乎不必要，他們將擁有字符串表。 – MerickOWA 2010-09-15 15:28:03
沒錯，所以你希望內部員工（尤其是未來的新員工）知道，當有人說'我的x查詢不起作用！'它們表示ID = 1的查詢。目的不是針對最終用戶，而是針對您的映射信息的內部支持人員。 – Beth 2010-09-15 15:30:57
+1給Beth。需要重申的是，應用程序不會是使用數據庫的唯一實體，並且該實體可能不知道該ID的含義。拋開本地化問題，所有ID最終都應該與數據庫中的「人類可讀」關聯起來。否則，它們在應用程序之外毫無用處，從而無法進行內部支持或臨時業務報告。 – 2010-09-15 17:04:23
啊這很有趣，我不知道檢查表的約束。 – MerickOWA 2010-09-15 15:42:00