原因就是
一定要用 Trigger 沒觸發就沒整合 系統平衡一定要用 Trigger
另外用途 :
有些地方不可以用 [ FK ] [ UK ]
就是要用 [觸發]
就是 : 前一個[欄位] 會更替另一欄位 [FK] 到不同 Table
就是用 [ FK ] 很難 [動態] 對應關連
使用的時機端看系統需求及系統設計者的想法:
1.重要(機敏)資料異動過程的紀錄(用於稽核、日誌記錄及其他用途)。
2.用於系統衍生資料產出。
3.應用系統間資料介接設計,例: 差勤系統中請假人完成請假流程,紀錄相關請假資料時,利用trigger將代理人及代理時段存入中介資料表,供公文系統使用,以正確完成公文傳送。
4.利用DDL trigger 防止未經許可的資料庫管理動作。(1.~3. 視為DML trigger)
5. .....
總之, 對標的功能的瞭解及累積經驗方是重點!
用Trigger的好處樓上go777大已經有說明,我也不可能說的比他好,所以就略過。
Trigger的確是個好東西,但是說實在的,我沒考慮用過,原因如下:
1.異質資料庫移轉問題:以前我幫客戶作專案,有可能今天客戶環境是MS SQL,過一段時間他會換成Oracle或MySQL,那我除了要幫他轉資料、改Connection String之外,我還要幫他轉換Trigger,我自認功力沒那麼高,而且大部份客戶總認為轉資料庫是件小事,不會付太多錢的。
2.維護問題:現在我有帶一組小小的程式團隊,在維護公司裡現有的應用系統,有時為了使用者需求新增改了Table Schema,我的要求是有異動就要更新SD文件,該講的也講了,該罵的也罵了,但每過一段時間去看,多多少少還是會有沒改到的地方,改個Table就這樣了,所以要用Tigger,我也要好好想想要怎麼留下修改記錄。
3.除錯問題:萬一資料庫有一筆的資料出問題是經由Trigger Update的,有可能新進程式師除錯三天都找不出問題出在那裡。
sam0407提到:
該講的也講了,該罵的也罵了
用踹的試試....
sam0407提到:
維護問題:現在我有帶一組小小的程式團隊,在維護公司裡現有的應用系統,有時為了使用者需求新增改了Table Schema,我的要求是有異動就要更新SD文件,該講的也講了,該罵的也罵了,但每過一段時間去看,多多少少還是會有沒改到的地方,改個Table就這樣了,所以要用Tigger,我...(恕刪)
還好你不是寫: 防空武器, 銀行金資系統,,,,
還好你不是寫: 防空武器, 銀行金資系統,,,,
因此一路真的很好
wiselou提到:
用踹的試試....
好建議!下次我試試,希望不會上蘋果....
albertachen提到:
真好
真天才
沒有 SD / SA 就自己寫, 還好你不是寫防: 空武器, 銀行金資系統,,,,
真讚, 沒有在 [開發機] 開發
真讚, 沒有在 [測試機] 測試
寫好沒 QA 就可以上系統
QA 沒需求文件, 沒去比對開發規格( SA/ SD文件)
真好
唉!阿伯大神準,一下就說中我的痛處....
好痛~~~不過算是所見略同,這些也都是我還再持續努力改善的地方。
我算是空降主管,剛來的時候更慘,連文件都沒有、每支程式的資料庫連結都寫死在程式裡、有些程式直接把User ID寫死在程式裡、有人離職時連程式碼都沒完整交接....總之是一堆問題。
這幾年我叫同仁把文件補齊、上程式版本控管系統、資料庫連結拆出來改寫成讀取參數檔(才有可能分測試環境及正式環境,預計今年下半年來作)、今年還要重改寫權限控管作Single sign on,雖然我也知道有待改善之處有很多,但這些都只能算是內部改善專案,畢竟我們也算服務單位,其他部門的專案還是要排優先順位的,部門資源也有限,只能說能改善一點算一點吧!
我是認為要看情況. 因為這會增加系統維護的複雜性.
如果關於兩個table的之間的一些連續動作, 那trigger很好用(例如當A table有修改時,觸發B table新增一筆某某某的資料, 而且B table是一些其他系統的table, 跟系統本身關係不大)
之於其他情況, 我還是比較喜歡用程式碼的transaction功能來代替...