令人苦惱的Paradox（第二集）

感謝一位不知名的網友提醒 Hxtt Paradox JDBC Driver 能存取Paradox資料庫，再加上業主對這個軟體 Single Server License 180USD售價爽快地付錢，我才能順利地使用Java去操作 Paradox DB。BLOB欄位也可以在慢慢地 try error 方式下，撰寫一個utility method解決Rich Text格式的text formatting轉換，在過程中，JUnit幫了大忙。

但這並不代表所有的問題都已經被解決了，在實作搜尋功能的過程中，我發現搜尋結果要在網頁上分頁呈現，對於Paradox來說是一件很辛苦的事情，我找不到類似Oracle的 rownum SQL語法（select * from table where rownum >=21 and rownum <40），如果要把SQL搜尋結果一次全讀進Sesion裡的一個暫存物件，如果搜尋結果是一千筆，就得花時間在SQL查詢->產生Value Object->存入Session裡面，不但耗時又耗記憶體。這個時候，偉大的 Lucene 出現了，對Lucene沒有深入研究的我，在Javaworld上所幸有 hkdennis2k 回答，我知道了當欄位資料以Keyword方式產生index時（ document.add(Field.Keyword("field", "abcd")) ），就可以使用 "a*"這種搜尋語法支援字首搜尋。這無疑是一個大好的消息，我馬上就能讓這個案子能以類似字典搜尋的方式，以非常快的速度支援"a*" 1000多筆資料 ->"ab*" 500多筆資料 ->"aba*" 50幾筆資料 的逐步搜尋。通常在第三個字母的時候，資料的數量就已經縮小到可以接受的範圍了，我無法想像，光用SQL要怎麼處理這種搜尋。

接下來又遇到了另一個問題，就是Hxtt Paradox JDBC Driver在Join table的時候，明顯覺得速度變慢，再將上摧殘DB的 "like" SQL語法（select * from table1, table2 where table1.field1=table2.field1, table1.field2 like '%somestring%'），這個時候，偉大的Lucene又被我搬出來使用，把對應的欄位都存入lucene index之後，犀利的搜尋功能馬上就能提升到「快狠準」的程度。結果現在我如果要重新產生lucene index，每次都得花將近一個小時，得到一個15MB資料夾大小的Lucene index。目前我不知道這麼大一個index到底有沒有任何缺點，但Lucene的確幫了我一個大忙。

目前功能已經完成約3/4，也開始準備要將畫面嵌入進美工畫面裡。感謝這些Open Source專案的幫助：
Tomcat Application Server
Lucene Search Engine
JUnit
DWR(http://getahead.ltd.uk/dwr/)
Eclipse IDE

ps. 可能不會有第三集，因為已經不需要再特別記錄什麼事情，現在只等著收尾結案了。