觸發器正確用法

關鍵字：架構設計 軟件質量保證 數據庫完整性

 

一、數據庫完整性討論

有許多同窗認爲開發階段不必創建外鍵約束，更不用創建檢查約束，由於會影響單表數據寫入作測試。

這個想法是很是錯誤的，不規範的，不專業的。

首先影不影響測試是無稽之談，說明這類同窗開發時不會寫單元測試，經過野路子來測試，質量不保。

而後完整性約束包含主外鍵約束的，是數據反應現實世界真實狀況的保證，若是沒有完整性約束，數據多是無心義的，那麼無心義的數據寫入了也是無心義，測試也是無心義，測試經過的只是一段無心義但結果湊巧對了的代碼。

 

因此嚴格設計數據庫，除了遵循範式以外，完整性約束是必須的。

 

二、觸發器的做用

不少時候代碼更加面向對象了，要求業務邏輯都能在代碼的業務邏輯層體現，是不推薦將業務邏輯分散到代碼、數據庫等多處，集中寫，集中管理。

因此觸發器和存儲過程將會更少地使用，那麼觸發器在當今代碼界還有什麼做用呢？

通常狀況是用來保證數據完整性和安全性。

 

咱們知道能夠給表中某個字段創建檢查約束（check），有一種狀況是檢查約束作不到的。

不能由於難作，就放棄了完整性的控制，檢查約束作不到，就用觸發器（插入性能損失，怕什麼！觸發器是能夠停用的，不能將鍋都甩給性能）。

 

咱們來看一個需求：

如今有一個遊戲，而後遊戲策劃搞了一次活動推出一個禮包，這個禮包只容許在活動期間充值5000元以上的用戶才能下單購買，活動期間等於禮包上架時間到下架時間，那麼除了在業務代碼中下單前檢查用戶在活動期間充值狀況之外，如何在數據庫完整性設計中體現呢？

---------------------------------------------

用戶（用戶id,用戶名）

用戶充值(用戶id,充值金額,充值時間)

禮包訂單(訂單id,用戶id,禮包id)

禮包(禮包id,禮包名,上架時間,下架時間,價格)

---------------------------------------------

一般，咱們在下訂單的時候，寫入禮包訂單表記錄，而後有外鍵約束的存在，驗證了禮包、用戶，那麼如何驗證用戶的充值呢？

沒辦法使用檢查約束吧，由於充值金額和禮包上下架時間並不包含在禮包訂單裏。

這個時候用觸發器就是正解了。