由AJAX設計導入來談資料庫資料分頁實作

程式碼說明版請連至 [Java技術論壇]

談到分頁這個問題，其實算是個討論到爛的設計，目前說法大抵可分「一次讀完」，與「建立索引」 這兩派。

一次讀完再慢慢地分，簡單來說就是一口氣將資料庫的屬於該邏輯的所有資料讀到記憶體中，再依使用者所要求的區間來呈現資料表內容。這方法的好處是可以降低平均整體查詢資料庫的時間，也就是降低與資料庫之間存取的頻率。而缺點就是必須提供大量的記憶體來儲存整個資料表內容，而且不能即時反應資料庫的變化。

建立索引的方式則是取得資料庫的資料表內含的索引，再讓使用者依照分頁索引來查詢出資料庫內的資料表該區間的資料。這方法的好處是僅需在記憶體內提供一些位置給使用者做資料表更新與索引表物件，缺點就是對資料庫的存取頻率較高，連結資料庫的動作所消耗的時間較多。

當然，有些額外的手段可以使資料庫查詢的動作簡化，就好比說是Connection Pool，這幾乎可以讓建立連結的時間忽略不計，而只需考慮到資料庫本身處理SQL語法的速度。但仍有些部分是無解（也不能這麼說，因為阿扁言：能用金錢解決的問題就不是問題。），那就是記憶體的使用量。

正因為金錢的來源是大問題，所以實際上要設計分頁還是要回歸使用者的使用習慣和查詢功能。若使用者的查詢習慣是只看前幾筆最新的內容，則一次讀完的方式顯然太浪費記憶體。又若使用者的習慣是將所有每筆資料逐筆查詢做運算，則建立索引的方式就顯得無用武之地。

既然使用者的習慣捉摸不定，那麼設計者就應要在介面上來隱性導引使用者習慣。好比說頁面僅呈現該區間資料的簡略屬性，若需要詳細資料，可再繼續按下按鈕調出詳細的屬性。而要調閱及時反應的最新資料，僅需使用者按下了分頁的第一頁，整批索引便立即更新，即可調閱最新一批資料。這些都是目前各開源的討論區作法的一部份。

而如今，有賴於AJAX的流行，我們更可以將所有資料作更分散式的取得，讓使用者有者近似於「一次讀完」的速度，又可以達到「建立索引」的記憶體節約。



上圖的分頁內容為使用「建立索引」的方式來呈現，搭配了Connection Pool之後，分頁的速度也頗為迅速。由於此服務的使用者習慣為檢閱最新資料以及指定時間區間的資料，因此在資料呈現上提供了最新十筆資料，並在右下角要求使用者一頁頁往前翻查，再不然也可以使用日期輸入器指定日期區間來做查詢。



接著，若按下了事件旁的按鈕，則會啟動AJAX function，將指定的單筆資料撈回做處理。由於不用換頁，因此此分頁的內容無須在重新reload，也無須重新查詢一次整個頁面的事件數。 即使系統忙碌，使用者也可藉由讀取中的小icon來得知目前正在等待事件事件內容資料，而不像目前一般討論區在閱讀文章遇到系統忙碌時，使用者只能看著瀏覽器底下的進度欄緩慢地前進，頁面空白一片，不知所謂。



當然，若要更狠一些，還可以將整個頁面都以JavaScript配合XMLHttpRequest來呈現出來，但我想那已經已經算是「純」Web 2.0 網站（Beta都應該還不算是吧！）的範圍了吧。

註： 「純」web 2.0，我想每個人心中都有一把尺，我認為像是Google ig、start.com、以及Windows Live Mail beta 的純度應該比Yahoo奇摩那些大得多