您應該為簡單永不更改數據（例如數學運算還是使用描述性文本）創建外鍵表嗎

Question

在我的數據庫中，我有一個規則表。 我的應用程序中的用戶可以建立許多規則，這些規則可以比較各個字段，例如FieldA大於FieldB 。 大於不是唯一的條件，可以在等之間用等號，小於號代替。

此條件需要存儲在我的“規則”表中。 我看到兩個選擇，一個是添加一列，其中包含用於標識它的文本。 數據看起來像這樣。

Id,Name,FieldId,FieldToCompareId,Condition
1000,RuleA,2000,2001,GreaterThan

第二種選擇是創建一個具有所有這些條件的外鍵表，並在規則表上有一個FK，就像這樣

ConditionTable            RuleTable
---------------           ----------
Id,ConditionName          Id,Name,FieldId,FieldToCompareId,ConditionId
1000,GreaterThan          1000,RuleA,2000,2001,1000
1001,Equals

第一種選擇是最簡單，最快的方法，缺點是條件的描述永遠不會改變。 如果我也添加了其他可以更改的列，則第二個選項似乎更好，例如，將顯示給用戶的描述性名稱，而不是在基於文本的應用程序中顯示出來。

第二個選項的主要問題是，我將在許多地方遵循此結構，因此最終將為非常靜態的數據創建許多不同的表，這也增加了在應用程序中訪問數據的復雜性。

第一種選擇是明智的解決方案，還是我應該始終重構外鍵表，以便僅將ID存儲在行中而不是文本中？

Answer 1

我發現，從長遠來看，第二種方法總能取得最佳效果。 麻煩在於設計，但是可以創建視圖以簡化數據訪問邏輯。 同樣，現代框架和設計人員已經內置了對此設計的支持，這使得創建用戶界面相當簡單。

如果選擇選項1，則可以添加其他字段以避免在應用程序層中解析文本。

無論哪種情況，您都可以采用與我過去類似的方法。 我創建了一個設計，該設計實際上將字段名和運算符存儲在單獨的字段中，以便可以構建動態sql查詢來實施規則。 大於，等於，IN，非IN ...

Answer 2

我相信您的兩種選擇都過於僵化，無法承受長期的業務需求變化

第三種選擇是不將信息存儲在數據庫中，而是將其存儲為應用程序類。 從長遠來看，如果您不需要允許運行時更新規則，那么這是最好的。

如果存在更新規則的要求，那么我建議使用更通用的方法，其中規則仍作為模板存儲在應用程序類中，並且僅將規則與所有此類規則綁定的目標對象的關聯存儲在單個中具有以下列的表：

RuleId int RuleParameters varchar TargetObjectType varchar
TargetObjectIdentier varchar

顯然，規則參數需要某種解析，才能將規則應用程序參數與目標對象相關聯。 而且，使用目標對象的類型和標識符（可以是復合鍵）來關聯目標對象也是如此，但是，從長遠來看，仍然是捍衛設計完整性的可行選擇。

希望能有所幫助，

Answer 3

回答問題的正確方法是考慮功能依賴性，以消除冗余。 如果選擇第一個解決方案，那么如何防止添加在數學上與RuleA相同的RuleB？ 那會是一件壞事嗎？ 如果RuleA被錯誤定義或誤用怎么辦？ 如果您想為用戶提供不同的規則列表怎么辦？ 如果您想總結規則使用或阻止某些規則怎么辦？

這些問題表明，在您的宇宙中，規則的定義與在條件中的使用無關。 因此，應獨立（按名稱）標識並按條件引用。

這也增加了訪問我的應用程序中數據的復雜性

不必要。 為此創建視圖。 您可以通過一次連接從第二個解決方案中復制第一個解決方案。