其中常量應該存儲在數據庫中

我一直在想，諸如「已批准，已拒絕，待處理」或「單身，已婚，已離婚」的常量是否應該組合在一個表中在數據庫中或在每個相關模塊的單獨表格中。哪一個更實用？其中常量應該存儲在數據庫中

2010-03-07 Jonn

爲了讓數據庫執行僅適用於引用表的外鍵約束，分開表。

2010-03-07 14:53:14

...仍然是基於db的方法，我絕對同意你的看法，菲利普。 +1 – mnemosyn 2010-03-07 14:56:42

在單個表格上分開表格會有什麼處罰？ – Jonn 2010-03-08 00:35:00

這些常數如何「常量」？我目前在代碼中存儲常量，因爲根據定義，它們可以不改變。如果它不是用戶配置的，請不要將它放在數據庫中。

在數據庫中存在這種類型的zillion外鍵約束是毫無用處的，如果這是任何問題，都會使您的性能遭受嚴重的影響。

但我知道我對此的看法很少被分享。

2010-03-07 14:55:54 mnemosyn

他們應該在單獨的表中，所以你可以使用外鍵。例如，假設你是在談論一個用戶表在這裏，如此設計的：

UserId   int 
Status   int 
MaritalStatus int

你可以定義一個UserStatuses表

StatusId int 
Name  nvarchar

與行的批准，未獲批准，並等待，然後對UserMaritalStatuses執行相同的方法。這也很好地映射到在引用這些表時在代碼中使用相同的常量。

2010-03-07 14:56:36

在我看來，你不應該在數據庫中存儲常量，將它們保存在代碼中。

你給我的兩個例子都會作爲ENUM存儲在數據庫中。

2010-03-07 14:56:37 Mark

我不喜歡根據字符串檢查記錄的狀態。這是對的嗎？ – Jonn 2010-03-07 23:28:39

我用過的大多數SQL實現都將enum的內部存儲爲一個整數，這個整數是一個允許的枚舉值的索引，就像C一樣。 SELECT應該對比索引而不是字符串比較。 – Mark 2010-03-08 03:49:15

我同意mnemosyn - 只要有可能，我會執行這些不能被具有約束而不是外鍵的用戶修改的東西。

但是，如果您需要在用於報告，BI或臨時用戶的查詢中包含用戶友好名稱，那麼就會出現一個錯誤。然後一個外鍵表將會非常方便。

2010-03-07 15:13:41 Ray

我不一定同意 - 事情**將需要被修改，並且更容易向查找表中添加新行，強制執行FK約束，而不必刪除並重新創建約束... – 2010-03-07 16:35:21

更容易，但多久會發生？如果您正在存儲狀態代碼（如「已批准，已拒登，待處理」問題），並且您的業務流程使此極不可能發生變化，那麼我認爲查找表的便利性遠遠超過了簡單性和性能約束。 – Ray 2010-03-07 16:44:12

這是關於您期望經常期望「維度」發展以及您期望它有多大的期望。如果這個維度的範圍很小（不到七個左右）和高度靜態的，比如婚姻狀況（單身，已婚，離婚，分居，喪偶，未知），那麼就不要將它映射到表格上。 – 2010-03-07 22:55:18

回答