[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想想。
彼此互助，好過一切動不了!!!