2017年12月15日 星期五

[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方式來讓他去執行。
假設有其失敗的時候,就把全部剛剛做的事情都還原回去。
這樣就可以不用這辛苦了。

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

[資安]社交工程

 社交工程 在資訊安全領域中所提出的"社交工程"議題,其實也可以說"溝通"一詞的另一個說詞。 人在討論交換訊息時的行為,正是所謂的社交工程的過程一模一樣,主要差異在於行為與意圖。 有心人士預計要蒐集他人的各種資訊使用的對話溝通方式,其中我們...