米血的小天地

看下圖的差異其實不難看出TODAY_2的時間是錯的，因為mm在Oracle是「月」的保留字(不管mm還是MM都是一樣的，沒有區分大小寫)

所以在抓時間的時候，取分記得要用「mi」，不要再用「mm」了

嘿嘿~~~SQL真的是一個很神奇的東西

有時候在多張表join時，很常會出現一對多的情況，如下圖，這實際上是同一筆資料，但被拆成兩筆，這種時候要如何用成一筆資料呢？

若今天我想撈取編號A0001~A0015的資料，語法會是

WHERE 編號 IN ('A0001','A0002','A0003','A0004','A0005','A0006','A0007','A0008','A0009','A0010','A0011','A0012','A0013','A0014','A0015')

公司沒有買PL/SQL的話就只能用免費的oracle db管理工具連DB囉...

連線設定方式：

在前篇有提到返回資料量小會走索引掃描，資料量大會走全表掃描。但有時候返回資料量小也會走全表掃描，如下面的例子：

今天我同事跟我反應開單建立日期時間的欄位顯示得很怪，如下圖。他希望改成日期+時間的格式。

先說結論：

1.就OR跟UNION ALL而言，是否走全表掃描與返回的資料量有關，若資料量大則走全表掃描，否則走索引(若Where子句的欄位有建立索引)，所以不是OR就代表會走全表掃描。

相信上過鼎X ERP技轉課或是有學過SQL的人都會認為使用EXISTS會比IN來得好，但其實這不是完全正確的。

尤其以SQL的可維護性角度來看，使用EXISTS比使用IN還來得不優，因若執行計畫出現Filter，則驅動表就會被固定，執行計畫也會被固定，也就是說無法透過執行計畫去優化SQL。而使用EXISTS這個固化子查詢關鍵字，如果又沒辦法對filter做unnest，則若優化器選到錯誤的驅動表，就會是很可怕的災難。