圖文版刊於： http://www.wretch.cc/blog/hougzou&article_id=4820636 談到分頁這個問題，其實算是個討論到爛的設計，目前說法大抵可分「一次讀完」，與「 建立索引」 這兩派。 一次讀完再慢慢地分，簡單來說就是一口氣將資料庫的屬於該邏輯的所有資料讀到記憶體 中，再依使用者所要求的區間來呈現資料表內容。這方法的好處是可以降低平均整體查詢 資料庫的時間，也就是降低與資料庫之間存取的頻率。而缺點就是必須提供大量的記憶體 來儲存整個資料表內容，而且不能即時反應資料庫的變化。 建立索引的方式則是取得資料庫的資料表內含的索引，再讓使用者依照分頁索引來查詢出 資料庫內的資料表該區間的資料。這方法的好處是僅需在記憶體內提供一些位置給使用者 做資料表更新與索引表物件，缺點就是對資料庫的存取頻率較高，連結資料庫的動作所消 耗的時間較多。 當然，有些額外的手段可以使資料庫查詢的動作簡化，就好比說是Connection Pool，這 幾乎可以讓建立連結的時間忽略不計，而只需考慮到資料庫本身處理SQL語法的速度。但 仍有些部分是無解（也不能這麼說，因為阿扁言：能用金錢解決的問題就不是問題。）， 那就是記憶體的使用量。 正因為金錢的來源是大問題，所以實際上要設計分頁還是要回歸使用者的使用習慣和查詢 功能。若使用者的查詢習慣是只看前幾筆最新的內容，則一次讀完的方式顯然太浪費記憶 體。又若使用者的習慣是將所有每筆資料逐筆查詢做運算，則建立索引的方式就顯得無用 武之地。 既然使用者的習慣捉摸不定，那麼設計者就應要在介面上來隱性導引使用者習慣。好比說 頁面僅呈現該區間資料的簡略屬性，若需要詳細資料，可再繼續按下按鈕調出詳細的屬性 。而要調閱及時反應的最新資料，僅需使用者按下了分頁的第一頁，整批索引便立即更新 ，即可調閱最新一批資料。這些都是目前各開源的討論區作法的一部份。 而如今，有賴於AJAX的流行，我們更可以將所有資料作更分散式的取得，讓使用者有者近 似於「一次讀完」的速度，又可以達到「建立索引」的記憶體節約。 http://pic22.pic.wretch.cc/photos/22/h/hougzou/4/1333974463.jpg 上圖的分頁內容為使用「建立索引」的方式來呈現，搭配了Connection Pool之後，分頁 的速度也頗為迅速。由於此服務的使用者習慣為檢閱最新資料以及指定時間區間的資料， 因此在資料呈現上提供了最新十筆資料，並在右下角要求使用者一頁頁往前翻查，再不然 也可以使用日期輸入器指定日期區間來做查詢。 http://pic22.pic.wretch.cc/photos/22/h/hougzou/4/1333974464.jpg 接著，若按下了事件旁的按鈕，則會啟動AJAX function，將指定的單筆資料撈回做處理 。由於不用換頁，因此此分頁的內容無須在重新reload，也無須重新查詢一次整個頁面的 事件數。 即使系統忙碌，使用者也可藉由讀取中的小icon來得知目前正在等待事件事件 內容資料，而目前一般討論區的閱讀文章，看著瀏覽器底下的進度欄緩慢地前進，頁面空 白一片，不知所謂。 http://pic22.pic.wretch.cc/photos/22/h/hougzou/4/1333974465.jpg 當然，若要更狠一些，還可以將整個頁面都以JavaScript配合XMLHttpRequest來呈現出來 ，但我想那已經已經算是「純」Web 2.0 網站（Beta都應該還不算是吧！）的範圍了吧。 PS： 「純」web 2.0，我想每個人心中都有一把尺，我認為像是Google ig、start.com、 以及Windows Live Mail beta 的純度應該比Yahoo奇摩那些大得多。 -- No Dying Skills, ● - Dame! New tech... but Lazy Users. .\) http://www.wretch.cc/blog/hougzou ___________ ﹒ ︵ √\ ___________________ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.129.165.41