要「查表」還是不？

Question

我目前正在爲一個項目設計一個數據庫。現在我正在辯論自己是否必須創建一個查詢表，例如「民事身份」數據，該數據只能包含單身，已婚，分居，寡婦/ W夫等固定值。我很確定將來不會再添加其他值。我應該把這些放在一個單獨的表上，或者只是硬編碼程序代碼的值？

Answer 1

對它們進行硬編碼有什麼好處？給定一個現代的ORM系統，從數據庫中讀取這些值並使用它們真的不容易嗎？如果是這樣，那麼我沒有看到的好處硬編碼當缺點是：

• 你必須重新部署，如果你想添加到列表中
• 你必須重新部署，如果你想改變拼寫
• 你可能想要的不僅僅是字符串（可能是ref-id或工具提示文本等）
• 你將不得不改變1000個記錄來改變文本如果您沒有存儲ref-id，那麼您存儲了該文件。

「我不認爲他們會改變」幾乎從來沒有像「他們不能改變」一樣。如果他們不能更改，如在True/False中那麼很好。如果你不想認爲他們會改變，而不是太多。

Answer 2

根據您的編程語言，將它們設爲常量或枚舉。沒有理由把它們放在數據庫中，因爲像你說的那樣，它們可能不會改變。

如果放在數據庫中，下一步是什麼？男/女？真假？ :)

我主要使用Java和所有這些項目作爲枚舉。我們的數據庫是MySQL，然後我們將列類型創建爲enum。尼斯甚至在那裏比賽。

HTH

Answer 3

我會傾向於兩者都做 - 使用查找表來實施參照完整性，並提供一個枚舉使代碼的可讀性。

缺點是，如果由於某種原因查找值確實發生了變化，您需要記住更新這兩個位置。

Answer 4

您應該在表格中爲CivilStatus（int）添加一列，該列是包含所有可能的民事狀態的CivilStatuses表的外鍵引用。

即使您不希望它改變，我仍然會從數據庫中查詢它。這將使本地化/全球化在未來更容易。

然後，您可以在您的代碼中枚舉枚舉，就像其他人所說的那樣，使映射更容易。但是，無論何時向用戶顯示文本，都必須來自數據庫或資源文件 - 而不是直接來自代碼。

Answer 5

正常化說：查找表

常識說：查找表

「民事結合」的概念並不是自然規律，它是民法的問題 - 這可以改變。

如果你需要根據項目中的公民聯盟身份做些什麼，安德魯凱南的做法是不錯的。否則僅僅查找表就足夠了。

Answer 6

查找表。爲什麼？

1）強制數據完整性。至少在列上加上檢查約束。

2）本地化

3）查詢問題。有時數據庫區分大小寫。

Select * from People where MarriageStatus = "single" or is it "Single", or is it "SINGLE" 

嗯，我不知道我最好把ToLower（MarriageStatus）=「單身」。 糟糕，我不知道圍繞列包裝功能阻止它使用索引:)

保存自己的一些麻煩，並使用查找表，除非這是一個低壽命的小項目。