giive 兄寫了一篇 Rails 內(nèi)建的 Pagination 簡(jiǎn)介 。不過(guò)官方 Rails Blog 推薦 的這篇文章 Guide: Things You Shouldn’t Be Doing In Rails ，強(qiáng)烈的建議不要使用內(nèi)建的 Pagination。甚至，在 Rails 2.0 還要完全的把 Pagination 移出 core 而獨(dú)立成一個(gè) Plugin。究竟這個(gè)內(nèi)建的 Pagination 有什麼問(wèn)題呢？
1. 雖然使用 paginate 時(shí)，產(chǎn)生的 SQL 不會(huì)將沒(méi)有要顯示的資料選取出來(lái)，但是有時(shí)候我們需要比單純的 find 來(lái)的複雜，會(huì)需要用到自訂的query。
正確的做法是做一個(gè)新的 class 繼承 Pagination，然後 override count_collection_for_pagination 和 find_collection_for_pagination 兩個(gè)method，(當(dāng)然你要在這兩個(gè) methods 中做出正確的 query)。再用這個(gè)新的 class 來(lái)產(chǎn)生 pagination。
不過(guò)很多懶惰人(就是我啦！)，會(huì)直接用 find_by_sql 把全部的 182,443,567,9832 筆的 records 選回來(lái)，再用 paginate_collection 來(lái)做出分頁(yè)的效果，自然就無(wú)比的浪費(fèi)。
這點(diǎn)不能算是 Pagination 的錯(cuò)，畢竟是亂用。可是因?yàn)閮?nèi)建的關(guān)係，讓很多人都沒(méi)有仔細(xì)去看看 Pagination 到底做了些什麼事，才會(huì)出這樣的問(wèn)題。
2. 使用 pagination_links 來(lái)產(chǎn)生選頁(yè)的連結(jié)是蠻慢的，根據(jù) 這一篇 ，用 pagination_links_each 會(huì)比較快。
不過(guò)若是分頁(yè)出來(lái)的頁(yè)數(shù)太多，會(huì)有放不下這麼多頁(yè)連結(jié)的問(wèn)題。這時(shí)要使用到 :window 這個(gè)選項(xiàng)，而這個(gè)選項(xiàng)是很慢很慢的。
所以說(shuō)，即使在沒(méi)有 Database overhead 的情況下，內(nèi)建的 Pagination 在資料量很大的時(shí)候還是會(huì)有效能的問(wèn)題。
解決的辦法？
參考這幾篇文章：
posted on 2006-11-10 21:19
老妖 閱讀(2081)
評(píng)論(1) 編輯 收藏 所屬分類:
轉(zhuǎn)載 、
rails