※ 引述《mrbigmouth (拒絕崩潰的蒲公英)》之銘言： : 在這種情況下，你需要的東西其實是Html產生器，一個幫你把資料變成Html頁面的東西 : 如果這個過程就是TonyQ大大所說的"以特定格式儲存再從伺服端取出"的"後端語言" : 那我認輸，至少在這個情況下認輸 : 因為整個處理過程根本只有一次嘛！當然是給處理能力最好的電腦去做.... : 但是 : 如果你的行事曆至少需要多人編輯、依登入者身份可以隨意插入、刪除、變更工作內容 : 工作內容有分級、分塊、分類，可以drill down跟roll up等等等的時候 : （依在下的不幸工作經驗來看，所有一開始看來很簡單的程式在之後八成都會 : 　在老闆/使用者的要求下加東加西，最後變成這種萬能的樣子） : 換句話說,資料進出資料庫的頻率很大的時候 : 前端就遠勝於後端了 其實以上我們是有共識的 也就是前端修改頻繁的狀況下，用 CLIENT 可以縮小更新的範圍， 也可以有效的進行互動。所以我就不多談了。 雖然我的表達應該讓你有誤會的地方， 我想主要的誤會在於我是把整理資料切成兩段的。 一段是純vo (json) ，另一段才是 vo => html。 我相信你應該也有切這兩段，只是你沒有特別標明而已。 另外 SEO 議題也只是 add-on 順便一提，你可以忽略這個子項沒差， 他不是很重要的重點，也有別的方式可以補償。XD 至於，我說的行事曆是主要用來顯示的狀況下， 靠後端組html就好了， 除非你有必要再畫面上點一點，日曆上就加個新項目（不換頁）。 或者畫面上按一按，東西就少一項，（不換頁）。 很多地方的作法是把新增刪除的表單往別的地方甚至別的系統扔， 這種狀況行事曆就只會是撈出來顯示。 這種情況，我不覺得非得要用前端不可啦， 反正小量的字串工作對後端真的是不痛不癢。 : 為什麼？ : 因為在工作交由後端處理的情形下，使用者每執行一次此類操作， : 伺服器就需要重新從DB撈一次資料、重新計算並且重新把資料傳遞給使用者 : 每次執行工作時,資料都需要跑一次DB->將原始資料編成適當格式->使用者的路程 : 而在前端處理的情況下，所有資料一進入記憶體就不太需要再從DB撈取，更不需要 : 再次經過網路傳輸的折磨 : 如下所示： : 狀況： : A.使用者登入並瀏覽此月行程 : B.使用者瀏覽下個月行程 : C.使用者在下個月插入新行程 : D.使用者返回瀏覽此月行程 : E.使用者重新整理 : F.使用者drill down瀏覽今日行程 : 後端處理情形： : A.使用者資料傳輸給Server->驗證使用者建立Session->從DB撈屬於這個月的行程出來-> : 將原始資料編成固定格式->資料傳輸給使用者 : B.使用者資料傳輸給Server->確認使用者身份->從DB撈出下個月行程資料-> : 將原始資料編成固定格式->資料傳輸給使用者 : C.使用者資料傳輸給Server->確認使用者身份->將資料插進DB->從DB撈出新行程資料-> : 將原始資料編成固定格式->資料傳輸給使用者 : D.使用者資料傳輸給Server->確認使用者身份->從DB撈出這個月行程資料-> : 將原始資料編成固定格式->資料傳輸給使用者 : E.使用者資料傳輸給Server->確認使用者身份->從DB撈出這個月行程資料-> : 將原始資料編成固定格式->資料傳輸給使用者 : F.使用者資料傳輸給Server->確認使用者身份->從DB撈出今日行程資料-> : 將原始資料編成固定格式->資料傳輸給使用者 : 前端處理情形： : A.使用者資料傳輸給Server->驗證使用者建立Session->從DB撈出所有使用者可見的行程 : 資料出來->以批次或者server-sent方式逐步傳遞給使用者->使用端將資料編成固定格式 : 展現 : B.使用端將資料編成固定格式展現 : C.使用者資料傳輸給Server->確認使用者身份->將資料插進DB->從DB撈出指定時間以後 : 有所異動的資料->資料傳輸給使用者->使用端將資料編成固定格式展現 : D.使用端將資料編成固定格式展現 : E.使用者資料傳輸給Server->確認使用者身份->從DB撈出指定時間以後有所異動的資料 : ->資料傳輸給使用者->使用端將資料編成固定格式展現 : F.使用端將資料編成固定格式展現 : 以上 以上這些我同意，如果你需要頻繁操作，透過前端當然比較簡單， 也可以只取你想要得部份。 : 最後 : 請不要把json說的好像不需要parse一樣... : 無論是什麼格式的資料,從server端傳過來的時候就只是字串 : 不管你是用eval還是各瀏覽器內建的parser, : 切CSV所花費的時間絕對小於轉換json的時間 等等，我覺得你要不要說說你怎麼 parse CSV 的？ 就我所知 , csv 要嘛就是用regex , 要嘛就自己split "," . (不管split 或indexOf+substring) 有比這更快更方便的方式嗎？ 我不是那麼常作csv，所以想確認一下。 如果沒有，我覺得你的「絕對」要打個折扣。 : 使用資料的類別更是跟使用者體驗八竿子打不著關係 : 只要用熟了就一點麻煩也不會有 這個前提是parse 需要花費時間，而花費時間動作多了 browser 會「鈍鈍的」。 當然我同意這種case底下，除非是ie6或ie7這種爛咖， 不然一般狀況應該都沒這問題。 : 當然,無論如何,前端花費的資源永遠只是小case : 重點在於後端要傳輸資料的時候 : 你要輸出json,就一定要先把所有資料存在記憶體裡才能一次轉換 並沒這回事，你csv能怎麼做，json就能怎麼做。 如果你嫌一次轉換一整個array太浪費資源， 你一筆一筆自己翻 string 轉也可以，這是轉換方法的問題。 沒有人規定你要「一次轉換」，事實上大量的資料我是不會這麼做， 這也是效能調校上的重點項目之一。 : 比如要把從DB resource讀出的資料一筆筆全部存進陣列裡...這過程是要吃記憶體的 : 小量的資料沒感覺,如果是一千筆、一萬筆資料呢?一個留言板的全部文章這種呢? : (特別是當使用語言是PHP陣列這種消費記憶體為實際N倍的怪物時) 你csv 能怎麼產，我就能怎麼產json。 : 從Server輸出CSV就不會有這種問題 我覺得這只是你用不對等的方式再比較這兩個東西。:P : json當然好用,我自己寫ajax時也有超過一半是在用json : 但json比csv好的優勢在於可以存進多層次、複雜的資料,而不是在效率 : 然後...從DB撈出來的原始資料,絕大多時候都是CSV能夠處理的 這個我不認為，這可能跟資料操作的習慣有關係。 csv 是扁平的，那意味著每次的資料都是獨一無二的， 你很難重用相同的資料在其他 request ... json 有彈性一點，不過這點要看設計習慣， 你覺得可以的話，我是不覺得有問題啦。 另外 json 可以透過 jsonp 輕鬆支援跨網域，這個彈性也是沒話講得。 : 在我上面所說的例子,當後端完全只負責撈DB與傳輸的情形下 : 完全可以使用CSV取代json,殺雞焉用牛刀 有關 csv 跟 json parsing 的部份，我想數字會說話。 對 test case 或者測量方法有不滿意的，可以自己改我們再來討論， 我因為一時想不到啥好例子，也真的是很懶得再找csv parser， 所以找一個對 csv 來講相對單純的例子， 實務上，csv 還要考慮 "" 跟 , 的差別，還會再慢一點。 http://jsfiddle.net/jnAW3/1/ 這個我特地讓 json 放點水，加上 "" 。 http://jsfiddle.net/jnAW3/2/ 本來想再測測 jsonp ，不過那個測試多少會被網路速度干擾，就算了。 基本上，如果你的資料超過八萬筆，那真的已經算是很了不起的了， 這就是為什麼我不太理解你所謂的解 csv 比 json 快的論述在哪。 它在chrome跟firefox 的數字還蠻飄的，看不出明顯差異， 在 IE 我的測試是相當明顯，另外可以比較 ie6,ie7,ie8 ,fx,chrome 的。 在IE6,IE7 上的數字，那可不是小case， 盡可能降低資料的操作量一直都是 performance tunning 上的重點。 可能我的觀念也不見得是對得，特別在效能議題上， 我們已經碰過很多次改個板，舊的觀念就大洗盤的狀況， 不過這個議題上到目前為止，我的論述只有兩個： 1.csv parser 你要引用外部類別或者自己寫複雜邏輯， 不好維護，也需要額外成本。（這是重點） 哪個是雞哪個是牛刀還很難說... 2.效能上沒有顯著差異，所以我完全想不到， 任何用csv parser取代 json parser的理由。 當然，這可能是測試案例的問題，只是我的認知跟你的認知有出入， 如果你可以有更好得例子，能說明 CSV 的好處，那也很歡迎。 -- 網頁上拉近距離的幫手 實現 GMail豐富應用的功臣 數也數不清的友善使用者體驗 這就是ｊａｖａｓｃｒｉｐｔ 歡迎同好到 AJAX 板一同討論。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 198.203.175.175 ※ 編輯: TonyQ 來自: 198.203.175.175 (12/23 00:42) ※ 編輯: TonyQ 來自: 198.203.175.175 (12/23 00:44) ※ 編輯: TonyQ 來自: 198.203.175.175 (12/23 00:44) ※ 編輯: TonyQ 來自: 198.203.175.175 (12/23 00:46) ※ 編輯: TonyQ 來自: 198.203.175.175 (12/23 01:08) ※ 編輯: TonyQ 來自: 208.54.38.134 (12/23 04:25)