DB實作心得---SQL JOIN語法

因為都是用Hibernate，所以好久沒碰這種語法了...老實說以前在學SQL的時候，也一直沒很認真的搞懂。一直到最近為了案子，才又比較認真的去看了...

找了幾篇網友分享的文章，都講得很清楚，所以就不在贅述：

• SQL Join語法筆記
• 用SQL合併資料表
• [SQL]Join的觀念

一般來說，我們通常都會儘量用一個SQL statement的方式來完成所需要的查詢。而其中都儘量可以用JOIN的方式來把所需要的資料串出來。不過我也有看到有網友發表心得，表示在MySQL上，進行較複雜的JOIN時，效率會很糟糕，甚至會造成DB table被lock過久的情況。事實上，幾年前我自己也用過MySQL，也是發現它在作較複雜JOIN時，效率真的不好...所以後來我就都改用PostgreSQL。

而在Hibernate中，我所常用的Criteria是一種物件式的查詢方式，它建立跟其他table JOIN的方式是透過createCriteria()或是createAlias()。透過這兩種method，可以把要查詢的root entity跟child entity作JOIN。在建立這種JOIN關係時，Hibernate預設是使用inner join的方式，所以在某些情況會無法正確的找到所要資料，甚至會出現LazyInitializationException。此時，可以試試看在這兩種method的呼叫時，加上Criteria.LEFT_JOIN，這樣Hibernate會以Left outer join的方式處理，也許就可以成功的找到所要的資料了。

我個人認為與其使用一個很複雜的SQL statement來增加查詢效率，未必比使用多個簡單的SQL statement來取出資料再透過自己程式邏輯作處理來的容易跟快速...

Database系統實做心得---SQL調校

做了很久跟DB有關的開發工作，但是其實後來大部分都是靠Hibernate為主。透過它，開發者不再需要傷神有關DB底層的設定與SQL語法的管理與維護。不過也變得比較偷懶，比較不會去在意SQL語法上的調校。

在網路上有許多高手有此道的獨到心得，我只也是從中獲得一點點，這兩偏是個人覺得還蠻不錯的：Database Index 筆記 與 調校 SQL 以徹底改善應用程式效能

其中有些跟DB table schema設計或是SQL語法的技巧，不過在Hibernate中，要使用這些技巧可能就不是那麼容易。Hibernate是允許使用者自行設定這些東西產生的方法，甚至可以自訂SQL statement。不過個人覺得Hibernate自己所產生的schema跟SQL statement已經很不錯了，除非真的很有特殊的需求，不然實在也沒必要自己搞（如果都要自己搞，那就失去用Hibernate的意義了）。

不過兩篇文章都有提到的一個重點：index。在Hibernate中，也有支援產生index的機制，但是只會對primary key跟unique column自動產生。雖然在Hibernate Annotation Extensions中有@index的annotation可以指定對某個property產生db index，但是這功能只有在透過Hibernate作第一次DB schema建立時有效；若是指定的index的table已經存在的話，這機制不會有作用，就必須手動產生。根據上面兩篇文章的內容，產生與刪除index的SQL DML為：

create index index_mytable_mycol on mytable(mycol)

與

drop index index_mytable_mycol

而根據上述兩篇文章的講法，幾乎都認為應該對FK也設定index比較好。當然有些但書，例如在主table資料量有到一定量以上的時候才會比較有效果等等的。

32bits vs 64bits part2, 32bits未必不好

之前就提過有關Snow Leopard的kernel mode的問題了...事實上我一直很困惑為何Apple不把Snow Leopard的kernel預設為64bit的。

當然，後來也去查過很多的文章，發現不管是國內外的一些使用心得或是報告，都是差不多的結論，就是32bit跟64bit的效能差異不大。其實我自己的感受也是一樣。而不管是使用者或是官方的說法都是說32bit kernel的相容性比較高...這點在我上次要透過iPhone來上往時也證實了...目前某些driver或是軟體可能是無法在64bit kernel下運作的。

當然，自己還是很不死心的測試了一下...用XBench...來測試32bit跟64bit的差異...結果...就分數來看兩者差異真的很小...才2~3分左右...事實上還是32bit贏的。而分項成績則是互有優勝，但是差距不大。除了在記憶體方面的項目中的allocation，64bit有大贏之外，其他的其實大部分都是差不多。而32在OpenGL跟一些圖形顯示方面是有些小贏...不管測幾次都一樣。剛好符合一些使用者的講法，目前在顯示driver上，Mac OS的32bit driver的最佳化是比較好的。

官方講法是說64bit kernel在安裝有大量記憶體（32G以上）的情況下才有需要啟動，而其他情況則與32bit無異。

不管怎樣，Snow Leopard的確讓64bit的app更加廣泛的被使用了，數量也變比較多...雖然還是不少32bit third-party app。能以32bit kernel來良好運作64bit app，apple的工程師也是夠厲害...

至於很多人都猜測，在下一版的Mac OS應該就會改變成為64bit kernel...我個人反而不是那麼看待...畢竟目前還是不少driver跟app還是32bit的...轉換為64bit kernel，對Apple來說會有好處還是壞處，還是難講...這也許也是Snow Leopard採用32bit kernel的原因。除非在新一版的Mac OS出現的時候，已經有更多重量級的driver跟軟體都轉換到64bit，否則用32bit kernel來運作應該還是必然的吧

講了一堆屁話，結論就是我又回到32bit kernel了XD

香草輸入法, 新酷音模組 & Snow Leopard

之前一直都是用Yahoo輸入法，是沒太多缺點啦...如果要說的話，就是猜字的準確度不高，而且不方便自己加詞。之前有人一直推薦我使用香草輸入法，但是Google之後，發現目前香草輸入法在0.9a1，看起來不算是很穩定的版本的感覺...而且我又是用64bit kernel，剛好又不在開發團隊有測試過的OS版本內，所以一直很遲疑...

但是，對於新酷音的猜字準確率很難忘，所以今天還是『冒險』一試了...為何說冒險...因為官網上有段話很嚇人：『請注意：輸入法屬於重要系統元件，系統可能因為輸入法軟體的bug而造成不穩或循環crash。如果發生這種情況，請以其他使用者登入後，砍掉輸入法元件檔案』...聽起來就感覺好像穩定度不高的感覺。

不過後來安裝，發現也沒想像中的難跟有問題...跟一般的Mac App安裝沒啥兩樣。不過...安裝玩香草輸入法之後，發現...沒有酷音模組...得另外下載跟安裝... 所幸官網文件還算詳盡。

試用的感覺：從活動管理員看，輸入法本身似乎所耗用的memory要比Yahoo的少蠻多，大概只有一半還不到，不過目前沒有for 64bit的版本（Yahoo的是64bit版本），所以只能用32bit啟動，但是使用上並沒有什麼問題，速度也算是很快。手動加詞的功能可以work，但是似乎只能按住shift之後，再按方向鍵的左鍵選擇詞彙長度，如果從輸入的句子中間開始往右選詞，則會失敗。至於穩定性，目前感覺不出來有啥大問題，可能要多用一陣子吧...

目前香草輸入法的進展感覺好像有點停擺了...目前的版本是2009.8月份的；而新酷音模組則更舊...感覺有點可惜就是...

Updated: 原來Yahoo奇摩輸入法也是有手動加詞功能，而且方法跟香草輸入法是一樣的

令人沮喪的事實？！Firefox的CPU 使用率問題

因為今天在公司用MacBook Pro，原本之前電池都可以撐很久的，但是今天卻只撐了3小時左右。讓我覺得有點納悶...所以剛剛查了一下...發現...Firefox會一直有CPU usage，即使只有一兩個很簡單且沒有flash的page而已...

當然，到Google上去搜尋，也是得到類似的結論...元兇的話，plugins是一大因素，但是我也用safe-mode的方式去啟動Firefox，但是還是會有持續的CPU usage，只是比有啟用plugins來的少一點。

感覺很「冏」啊...Firefox的一大優點就是有豐富的plugins來幫助瀏覽，但是...現在卻也變成CPU使用率的大怪獸...也許會有人覺得：反正只是多耗一點點的CPU usage，現在CPU都那麼powerful，沒差啦...
但是如果是在筆電尚且使用電池的環境，這可就有很大差別了...因為持續不斷的CPU usage會讓系統處於busy的狀態...CPU就無法進入比較省電的模式了，自然電池就會很快用完....

嗯...真是兩難啊....看來如果用電池模式的話，可能不適合使用Firefox吧...使用Safari跟Google Chrome倒是都沒這種問題。

P.S: 除了發現Firefox有這問題，M$的Messenger for Mac也會在沒動作的情況有CPU usage，但是沒有像Firefox那麼嚴重

Update: 後來發現原本以為應該不會有動作的Google搜尋結果頁面，其實似乎也是有javascript在背後慢慢跑？！為何這麼說呢...因為在Safari、Chrome跟Firefox都發現同樣的情況...但是，結論還是沒有變，Firefox在CPU使用上還是偏高。在改用Safari跟Chrome之後，MacBook Pro的溫度明顯降低。

Snow Leopard的Kernel mode的真相

Snow Leopard這次的賣點之一，就是64bit，強調64bit帶來的效率與好處。而Snow Leopard這次的確把大部分的內建軟體都改版為64bit了。

但是，有趣的是kernel的部份居然還是使用32bit，而更有趣的是在32bit的kernel之下，透過「活動監視器」去看，卻是會看到有軟體是以64bit來運作的。相當神奇吧？至少我是這麼認為...當然也許是我認知錯了也說不定啦

如何讓Snow Leopard真正的以64bit運作呢？也很簡單，只要開機過程時，按著6跟4就好。但是這種方式只有在該次開機有效，重開機之後，就會回到32bit了。想要永久的切換的話，可以安裝一個SixtyFourSwitcher，透過它就可以做永久性的切換了，不管是從32->64還是64->32。

切換到64bit有何好處呢？理論上是會效能更好一點啦...但是其實在Snow Leopard上面的話，感覺到不是很明顯（不過我在Ubuntu上倒是有比較明顯的感覺）。也許是目前為了兼具32與64bit共存的情況，所以還沒辦法完全發揮64bit的能力吧。不過可以在不用重新安裝的情況，就切換kernel mode，這也算是一項特點。至少在Windows跟Linux上，都必須重新安裝64bit的版本才行。

MacBook Pro + iPhone 3GS的行動上網

前天因為使用的SEEDNET數位光纖突然大斷線，導致沒辦法上網。後來想到，iPhone有「internet 分享」的功能，剛好又是3G費率吃到飽的方案，所以試了一下...

設定很簡單，只要到iPhone的「設定」->「一般」->「網路」->「internet共享」打開就好。然後它會要你選擇只用USB共享還是USB跟Bluetooth都啟用。如果有USB連接線的話，建議只開USB就好，可以一邊充電一邊上網。開啟之後，將iPhone連接到MacBook Pro，就會在Mac OSX上看到找到新的網路裝置，叫做「iPhone USB」，選擇它作為連線的網路裝置即可。

不過，實際試的時候，卻發現不能work...怎麼設定跟連結就是不能透過USB來連線...但是如果有啟用Bluetooth，則是可以透過Bluetooth來連線，但是速度就會變比較慢。後來詢問Google大神之後，發現...原來如果啟用Snow Leopard的64bits Kernel模式，就沒辦法透過USB的方式連結。所以只好先把kernel模式改回32 bit再重新啟動。果然，就可以順利連線了。

使用心得的話，3G上網其實還是蠻不錯的，雖然速度不及於數位光纖，但是也在可以接受的範圍了。不過訊號穩定性是個問題，因為有時候會有突然變慢的情況。不確定在使用「internet共享」的時候，能不能收發電話，有試過但是發現，有時候會造成網路斷線，但是有時候又不會。

不能在64bit kernel mode下使用USB的internet分享，是唯一美中不足的地方...畢竟Snow Leopard的賣點之一就是64bit~