數據庫在用戶名稱字段上有一個唯一的約束索引。數據庫約束是否映射到業務邏輯
通過
service.GetUser(userName);
業務服務會檢查用戶名是否已經存在。由於該服務中的邏輯,永遠不會插入重複的名稱。我沒有發現號碼爲2627的SqlException
的例外情況,這是違反唯一約束條件的。
那麼,爲什麼我會把一個唯一的約束放在名稱字段?
數據庫在用戶名稱字段上有一個唯一的約束索引。數據庫約束是否映射到業務邏輯
通過
service.GetUser(userName);
業務服務會檢查用戶名是否已經存在。由於該服務中的邏輯,永遠不會插入重複的名稱。我沒有發現號碼爲2627的SqlException
的例外情況,這是違反唯一約束條件的。
那麼,爲什麼我會把一個唯一的約束放在名稱字段?
由於服務中的這種邏輯,永遠不能插入重複的名稱,所以爲什麼我應該在NAME字段上添加一個唯一約束?
由於沒有其他好的方法可以保證在數據庫的整個生命週期內沒有應用程序通過該服務添加數據。
我熟悉的每個dbms包括一個命令行界面,一個圖形界面和一個批量加載程序。這使得至少有三個應用程序可用於修改數據,而無需通過service.GetUser()。
將UNIQUE約束放置在數據庫層可確保不管重複的名稱在插入點(或更新)的入口位置發生時都不會發生。例如,如果您將其留給應用程序層以確保唯一名稱,那麼如果有人直接從命令行插入行,或者應用程序範圍外的批處理腳本會發生什麼情況?
IMO,最好在數據庫層保持這種獨特的約束行爲。
您應儘可能多地在數據層上放置業務邏輯。關係,唯一性,長度,最小長度,價值限制,無論你可以。
不要相信應用程序將其正確放入,數據用戶將嘗試以任何可能的方式將其分解。我個人認爲,發送500錯誤數據比接受它並稍後修復更好,儘管有些人會告訴你,否則,因爲這是一個非常有爭議的問題。
祝你好運。
同意荷魯斯100%。 – 2012-03-15 20:08:52
喜歡你的答案主要:) – Pascal 2012-03-04 08:58:08