图文版刊於： 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