程式碼說明版請連至 [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奇摩那些大得多
Subscribe to:
Post Comments (Atom)
[遊記] 香港三天兩夜
在五月初起意找時間離開台灣去流浪,連續三年無視了公司的員工旅遊補助,今年終於給了自己動力離開台灣三天兩夜出去走走,即使目的地只是航程不到兩小時的香港。 決定了日期,向公司請好了休假,接下來就是要決定交通住宿,由於想要自己決定出發以及回來時間,方便起見捨棄了可能有特定優惠的機...

-
週日早上趁著還有陽光,帶著相機朝著陽明山出發。尋著北投後山泉源路往上,在不斷的左轉之後,每次都在最後關頭右轉東昇路進入陽明山國家公園的我,第一次踏上了「 登山路 」。延著「登山小棧」(這其實是店名)的提示往上走,到達最上頭的停車場之後,便可下車開始繼續由登山步道健行而上。 今...
-
有隻小小的花貓,就稱她叫做阿喵吧! 阿喵住在一間很普通很普通的公寓,與主人在一起。 阿喵喜歡黏在主人身邊,尤其當主人坐在桌前讀著書時,阿喵總是迫不及待地蜷伏在主人的腿上。 當主人出門時,阿喵也總是安靜悠閒地睡在桌前的椅子上,等著主人回家。 這隻小小花貓的主人,就姑且稱他為...
-
程式設計,最讓我著迷的是那種從無到有的那種「純粹」。我用這目前所擁有的所有知識與經驗,賦予了這個孩子為人所不能的優點,同時也賦予了一些不可為的缺憾,但我卻可以在我靈光乍現的時刻,將缺憾從程式的生命中抽離,這種種「純粹」,是一種程式設計師自身生命的體現。 程式設計的過程...
No comments:
Post a Comment
有什麼想說的嗎?