第二十篇:記下第一個mysql觸發器
阿新 • • 發佈:2018-11-09
專案背景:
給一個服務限制訪問次數,當用戶訪問這個服務的次數達到這個值的時候,關閉他的訪問許可權
首先訪問資訊存在一張表中,記錄使用者的ip:visitor_ip,服務的id:service_id,訪問次數:total_count
另一張表存的是該服務的許可權資訊, service_id關聯,limit_visits為閾值
第三張表存放 service_id,visitor_ip;有這個匹配對的該ip下的使用者無法訪問這個id的服務
首先想到用定時任務,不斷輪詢去統計 ,
問題是:使用者訪問服務的行為是隨機的,訪問資訊表的變化也是隨機的,這樣去輪詢做統計做判斷執行操作,增加訪問資料庫的壓力不說,每次輪詢完了要在程式裡做各種迴圈判斷;第二個問題是,定時任務的時間間隔,時間短了資料庫表查詢和程式判斷後執行的動作恐怕來不及,時間長的話,某些使用者可能就在這個間隔裡突然瘋狂訪問,沒來得及下次任務開始,已經達到閾值
觸發器是個好東西
設計如下,mysql的版本
觸發器的貼幾條現成的:
1. 自動執行。觸發器在對錶的資料作了任何修改(比如手工輸入或者應用程式的操作)之後立即被啟用。
2. 級聯更新。觸發器可以通過資料庫中的相關表進行層疊更改,這比直接把程式碼寫在前臺的做法更安全合理。
3. 強化約束。觸發器可以引用其它表中的列,能夠實現比CHECK約束更為複雜的約束。
4. 跟蹤變化。觸發器可以阻止資料庫中未經許可的指定更新和變化。
5. 強制 業務邏輯。觸發器可用於執行管理任務,並強制影響資料庫的複雜業務規則。
所以,以後觸發器,可以多多的嘗試在專案中使用,以減少某些繁瑣的業務
給一個服務限制訪問次數,當用戶訪問這個服務的次數達到這個值的時候,關閉他的訪問許可權
首先訪問資訊存在一張表中,記錄使用者的ip:visitor_ip,服務的id:service_id,訪問次數:total_count
另一張表存的是該服務的許可權資訊, service_id關聯,limit_visits為閾值
第三張表存放 service_id,visitor_ip;有這個匹配對的該ip下的使用者無法訪問這個id的服務
首先想到用定時任務,不斷輪詢去統計 ,
問題是:使用者訪問服務的行為是隨機的,訪問資訊表的變化也是隨機的,這樣去輪詢做統計做判斷執行操作,增加訪問資料庫的壓力不說,每次輪詢完了要在程式裡做各種迴圈判斷;第二個問題是,定時任務的時間間隔,時間短了資料庫表查詢和程式判斷後執行的動作恐怕來不及,時間長的話,某些使用者可能就在這個間隔裡突然瘋狂訪問,沒來得及下次任務開始,已經達到閾值
觸發器是個好東西
設計如下,mysql的版本
好了,踩了一些坑,最後我要說,請用Beaytiful SQL先美化一下格式,排錯的時候,直接定位到某一行去找錯誤.........
觸發器的貼幾條現成的:
1. 自動執行。觸發器在對錶的資料作了任何修改(比如手工輸入或者應用程式的操作)之後立即被啟用。
2. 級聯更新。觸發器可以通過資料庫中的相關表進行層疊更改,這比直接把程式碼寫在前臺的做法更安全合理。
3. 強化約束。觸發器可以引用其它表中的列,能夠實現比CHECK約束更為複雜的約束。
4. 跟蹤變化。觸發器可以阻止資料庫中未經許可的指定更新和變化。
5. 強制 業務邏輯。觸發器可用於執行管理任務,並強制影響資料庫的複雜業務規則。
所以,以後觸發器,可以多多的嘗試在專案中使用,以減少某些繁瑣的業務