有了新方法還需要舊觀念嗎？

文 – 楊振源

ERP系統當中有許多的交易檔，都與庫存帳息息相關，比如驗收入庫則庫存增加，銷售出貨則庫存減少。

記得20幾年前DOS的時代，老是為了電腦系統上的庫存量的正確性大傷腦筋，因為當一筆出貨交易完成更新以後，又要再做數量的修改，就必須加舊減新，假如再加上同時又修改了料號，則計算邏輯就更複雜了一點，這樣的程式撰寫方式又被稱為On-line Update。為了解決技術上的難題，大家就創造了Batch Update的方式，也就是出貨單key-in完畢存檔的時候，並不去Update庫存主檔，必需在User按了過帳的時候才批次更新庫存。這樣解決了程式的難度問題、DB Commit/Rollback的技術問題、以及DB Performance的問題。

時至今日，20年過去了，現有國內多數ERP系統廠商，卻仍停留在20年前，僅僅把DataBase當作儲存資料的地方而已。仍舊沿襲著舊的做法繼續採取批次過帳的方式。

這樣的方式有哪些何問題?
(1) 庫存即時性的問題，必需按過帳(或稱確認或稱核准)才會更新庫存，庫存不即時
(2) 疊床架屋的問題，假如出貨通知單(或稱備貨單)可為Locking庫存用，則未過帳的出貨單顯然是重覆的單據
(3) 操作便利性的問題，假如過完帳後要修改資料，則必須過帳還原，而往往在過帳還原的時候庫存被不當的搶走，或還原的時候造成庫存不足，而必須採取其他補庫存的特殊奇怪作業

是什麼新方法可以解決程式的難度問題、DB Commit/Rollback的技術問題、以及DB Performance的問題? 答案很簡單，運用DB的Trigger功能。
(1) 程式的難度問題，DB Trigger可以分開處理Insert/Update/Delete的程式碼
(2) DB Commit/Rollback的技術問題，程式只要控制出貨單的Master/Detail就好了，只有在出貨單被Commit成功，Trigger才會被執行，所以不需要擔心資料寫入一半的問題
(3) DB Performance的問題，使用Trigger則她的所有資料處理都在DB Server上完成，可徹底解決DB Performance的問題

過了20年，已經有了新方法、新工具，是不是應該放棄舊的觀念與做法!!