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

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

[SQL]Join的觀念

最近工作寫SQL時，突然發現一個有趣的觀念會讓人搞混與疑惑。
例如說JOIN的觀念。
畢竟JOIN可以說有幾類
inner join
left join
right join
full join

這四項。

其實一般最常被使用的就是INNER JOIN。
如：
select * from student a,course b where a.s_id=b.s_id
這樣的寫法其實就是
select * from student a inner join course b on a.s_id=b.s_id

至於結果呢!
就是所謂的有AB交集的才顯示

其二LEFT JOIN
就是以左邊為主，左邊資料表全數顯示，右邊資料表有對應到的話就是顯示資料，沒對應到的話就是顯示空白。
以數學就是A再加上AB交集的區域

其三RIGHT JOIN
使用方式與LEFT JOIN一樣，但方向剛好相反。
以數學說明就是B再加上BA交集區

其四FULL JOIN
顧名思義就是全部一起來。
就是所謂的聯集拉，有對道就顯示資料沒對道就給她空白值

一般大概就是這四種吧，別再搞混了喔。
懶得畫表個，因此今天只有簡單說明觀念。

[coding]寫程式的心得(一)

不管怎樣的程式設計師，相信都會有寫到開始感到煩躁的時候。
最大的發生時間我想莫過於看到一大堆程式碼被註解掉，
甚至連註解原因都沒有的時候。
我想這時候因該會出現所有我們所想到的國罵吧。

雖說註解程式或許可以幫助當下開發時的還原與比對。
但是當功能確認後，那些已被註解的程式碼就淪落到因該要被刪除的程式碼時。
不用想了，立刻、馬上、即刻 刪了。

為甚麼要這麼強烈呢!

其實很簡單，
依照我個人的經驗整理下來大概有三點
1.註解人知道這是垃圾，但交接人不知到的機率高達八九成。

2.留下太多註解會造就程式的容量龐大。(因該會有人說只不過差個1、2K，但數量一多，每一隻都多個1、2K 一個系統就有多少程式，會造就多少無謂空間的浪費)

3.註解程式碼，別忘了操作網站的不單單是一般使用者，還有高階電腦技術人員，哪個心懷不軌的人把你的程式註解部分打開，嘿嘿嘿~大家吃不完兜著走吧。

這三點看起來就像是MIS的發牢騷吧!

其實真正可怕的只有第三點。

大家一起想想我們過去是不是有相同的程式碼，花個時間整理整理，搞不好會對初出茅廬時的自己感到貽笑大方吧!!

[SQL]程式設計小觀念

有些系統需求會為了方便使用者使用而出現所謂的"勾選執行"、"全部執行"。

當然顧名思義看起來又是把"個別執行"的指令多下幾次給資料庫即可達到的需求。
但是
千萬別這麼做。

個人的悲慘經驗是，寫程式的人可能出有這樣的思維｢反正需求可以達到」。
但是這麼做的話下場就是對資料庫的存取次數過多，甚至可能多到直接當掉的可能。
當然Program designer 一開始並不會想到這麼多。

而且最常出現的回應是"去加強硬體設備吧!"

其實我個人也覺得加強硬體設備是手段之一。
但指令也是可以優化的。

如：
個別執行
product_id為1 的價碼更新為100
update product set price='100' where product_id='1'

選擇執行/全部執行
product_id為1與2 的價碼更新為100
update product set price='100' where product_id='1'
update product set price='100' where product_id='2'
或者
update product set price='100' where product_id='1' or product_id='1'
又或者
update product set price='100' where product_id in('1','2')


有沒有發現選擇執行/全部執行可已有三種寫法。
其中第一種存取數會很多，第二種寫的一堆OR 第三種則是用in 搞定一切
或許各有優缺。
目前讓我發現最大的缺點就是存取數過多會造成服務滿載的現象。

所以程式設計師或許不是DBA但在系統設計時替DBA想想。
彼此互助，好過一切動不了!!!

[SQL]資料庫資料搬移 insert select

程式設計時偶爾會有出現暫存表的使用需求。
當然有些設計是考慮到union或暫存表哪個速率快。
因此會有出現需要進行資料搬移的需求。
太久沒用這類需求，難得使用到，因此記錄下來方便以後參考用。

create temp_table (欄位)

建立暫存表的概念跟建立實體表一樣。
之後當然就是資料搬移的問題。
過去有些做法是利用程式的迴圈把資料一筆一筆讀出來之後再依比一比的insert到另一張表。
但這種作法雖然以程式設計人員而言可以掌控的很完整，但缺點就是需要多次存取資料庫的需求。

當然，其實資料庫本身就有其功能。
簡單範例概念如下：
insert table1(col1,col2)
select col1,col2 from table2 where 1=1

這樣就能直接一個請求需求，就達到資料搬移的效果了。

[生命分享]時間分配

每天都在抱怨時間不夠用嗎!
還在每天加班工作當作是比較認真地為公司賣命嗎!

這樣搞壞身體有誰賠呢!

當然各個職位都有他必須忙碌的事情。
我只能在這分享一些我的個人經驗與方法。
1. 工作分類
2. 進行捨棄與整理
3. 適時調整與休息

1.工作分類
每個職務上都會有一些所謂無意義的雜事存在。
因此可以嘗試將預計今日要完成的工作與被交代的臨時任務做一下分類。
以早上三小時規劃、下午五小時執行的大體分類。
早上三個小時可以進行一些訪談需求確認、資料彙整、行政文件的編輯與交付作業。
下午五個小時可以進行需要連續思考的開發、維護、設計這類需要較為耗時與專注的工作。

2. 進行捨棄與整理
職場上工作是不可能有作完的一天，唯獨有做到一個段落的情況。
因此我會想把一些工作先行彙整後再來評估捨棄工作。
當然這裡的捨棄不是直接不理會該項任務，
而是可以選擇性的交代其他可以協助完成的人協助完。成。
例如說：資訊工程師需要維護與整理環境，若此時兩項工作都要執行時其實我們可以很清楚地因該捨棄整理環境這個選項，因為以工程師而言開發維護作業為第一要務。
但我個人則會有一點點不太一樣的想法，當心中對要開發的項目存在的疑惑與疑問時，我會先選擇整理環境。
此時一般因該會出現一個疑問，為甚麼是整理環境，而不是認真思考開發。反而是捨棄開發這個選項。
或許是個人習慣吧或是經驗給我這樣的思維吧，當身邊的環境混亂時，也會讓自己的思緒跟著混亂。因此開發這類需要思緒清楚的工作執行前，我都會把環境整理好。
所以"捨棄"是要捨棄急躁的情緒，"整理"是要整理好自己的腦袋。

3. 適時調整與休息
有些人的確可以一直工作不休息，但是別忘了!!!
機器用久了要進廠保養。
身體用久了也會生病的。
因此當我們感到累了的時候，就別再繼續了。
休息五分鐘，絕對比連續加班一小時來的報酬率高。
畢竟加班工作換來的會是品質不佳的結果。
那倒不如休息一下，身體、腦袋都冷靜了再來進行工作。
相信可以提高不少效率。

以上是小弟個人自工作到現在的一些小小心得，提供在這讓大家分享。