2006/4/18

令人苦惱的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. 可能不會有第三集,因為已經不需要再特別記錄什麼事情,現在只等著收尾結案了。

沒有留言:

張貼留言