[SQL]transaction的救援

最近在處理資料同時存取時出現異常的狀況。
研究了一下程式寫法後發現一些小瑕疵，
就是在撰寫多人同時使用的系統程式時，
再進行資料庫存取觀念要做一些注意。

雖說交易管理的觀念是在資料庫管理的基本觀念，
但在程式設計時還有會有被忽略的時候。
畢竟有些程式開發的時候，初步規劃會有單人單機操作的規劃設計。
因此會出現一些看似可行的做法。

最後多人同時上線作業時就會出現異常資料的可能性就會常常出現。

因此特別把交易管理的觀念在這裡紀錄一下。

一般而言，對資料庫存取時無非是insert、update、delete、select這四個動作。
但是除了select以外，其他的存取基本上都有可能出現互相影響的可能性。
因此需要知道資料庫的commit跟rollback這兩個觀念。
其實就是commit跟commit間可以有多個select指令。
但是如果遇到有update或insert的時候就需要去注意一下。
(會特別講是這兩個是因為小弟就是被這兩個指令害了，被轟了一天。哈哈)

在insert新資料時入沒有交易觀念的話，程式可能會出現同時insert的異常，而造成會有一些神奇的異常資料。
其實就是每一個指令在進行修改時，需要先鎖定該資料表，讓該資料不得因為其他指令而被修改。

這邊可能需要一些繪圖才能容易說明。
說簡單一點就是需要讓指令間會互相排隊等待。
如A下的指令到commit之後B下的指令才可以被執行。
這樣才能排除同時下指令的狀況出現。

至於為何會提到rollback這個指令呢?

其實很簡單
就是我們在下一次commit之前，可能會是做了很多條的更新指令。但是如果其中一條錯誤時，要還原資料難不成要DBA連入資料庫手動修改嗎?(可憐的DBA)

因此我會利用try catch方式來讓他去執行。
假設有其失敗的時候，就把全部剛剛做的事情都還原回去。
這樣就可以不用這辛苦了。

附送一句關鍵詞"不做好自動化，就自己做到死"