關鍵字：架構設計 軟體質量保證 資料庫完整性 1、資料庫完整性討論 有許多同學認為開發階段沒必要建立外鍵約束，更不用建立檢查約束，因為會影響單表數據寫入做測試。 這個想法是非常錯誤的，不規範的，不專業的。 首先影不影響測試是無稽之談，說明這類同學開發時不會寫單元測試，通過野路子來測試，質量不保。 然 ...
關鍵字：架構設計 軟體質量保證 資料庫完整性
1、資料庫完整性討論
有許多同學認為開發階段沒必要建立外鍵約束，更不用建立檢查約束，因為會影響單表數據寫入做測試。
這個想法是非常錯誤的，不規範的，不專業的。
首先影不影響測試是無稽之談，說明這類同學開發時不會寫單元測試，通過野路子來測試，質量不保。
然後完整性約束包含主外鍵約束的，是數據反應現實世界真實情況的保證，如果沒有完整性約束，數據可能是無意義的，那麼無意義的數據寫入了也是無意義，測試也是無意義，測試通過的只是一段無意義但結果湊巧對了的代碼。
所以嚴格設計資料庫，除了遵循範式之外，完整性約束是必須的。
2、觸發器的作用
很多時候代碼更加面向對象了，要求業務邏輯都能在代碼的業務邏輯層體現，是不推薦將業務邏輯分散到代碼、資料庫等多處，集中寫，集中管理。
所以觸發器和存儲過程將會更少地使用，那麼觸發器在當今代碼界還有什麼作用呢？
一般情況是用來保證數據完整性和安全性。
我們知道可以給表中某個欄位建立檢查約束（check），有一種情況是檢查約束做不到的。
不能因為難做，就放棄了完整性的控制，檢查約束做不到，就用觸發器（插入性能損失，怕什麼！觸發器是可以停用的，不能將鍋都甩給性能）。
我們來看一個需求：
現在有一個游戲，然後游戲策劃搞了一次活動推出一個禮包，這個禮包只允許在活動期間充值5000元以上的用戶才能下單購買，活動期間等於禮包上架時間到下架時間，那麼除了在業務代碼中下單前檢查用戶在活動期間充值情況以外，如何在資料庫完整性設計中體現呢？
---------------------------------------------
用戶（用戶id,用戶名）
用戶充值(用戶id,充值金額,充值時間)
禮包訂單(訂單id,用戶id,禮包id)
禮包(禮包id,禮包名,上架時間,下架時間,價格)
---------------------------------------------
通常，我們在下訂單的時候，寫入禮包訂單表記錄，然後有外鍵約束的存在，驗證了禮包、用戶，那麼如何驗證用戶的充值呢？
沒辦法使用檢查約束吧，因為充值金額和禮包上下架時間並不包含在禮包訂單里。
這個時候用觸發器就是正解了。
