1、數據庫完整性討論

有許多同學認為開發階段沒必要建立外鍵約束，更不用建立檢查約束，因為會影響單表數據寫入做測試。

這個想法是非常錯誤的，不規范的，不專業的。

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

然后完整性約束包含主外鍵約束的，是數據反應現實世界真實情況的保證，如果沒有完整性約束，數據可能是無意義的，那么無意義的數據寫入了也是無意義，測試也是無意義，測試通過的只是一段無意義但結果湊巧對了的代碼。

?

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

?

2、觸發器的作用

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

所以觸發器和存儲過程將會更少地使用，那么觸發器在當今代碼界還有什么作用呢？

一般情況是用來保證數據完整性和安全性。

?

我們知道可以給表中某個字段建立檢查約束（check），有一種情況是檢查約束做不到的。

不能因為難做，就放棄了完整性的控制，檢查約束做不到，就用觸發器（插入性能損失，怕什么！觸發器是可以停用的，不能將鍋都甩給性能）。

?

我們來看一個需求：

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

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

用戶（用戶id,用戶名）

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

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

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

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

通常，我們在下訂單的時候，寫入禮包訂單表記錄，然后有外鍵約束的存在，驗證了禮包、用戶，那么如何驗證用戶的充值呢？

沒辦法使用檢查約束吧，因為充值金額和禮包上下架時間并不包含在禮包訂單里。

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

總結

以上是生活随笔為你收集整理的SQL触发器基础的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。