→ mrbigmouth:寫的滿亂的 請所有看完傷眼的人見諒 12/22 22:11
→ mrbigmouth:再不滿意的話...恐怕只能寫個實例出來比較了 12/22 22:11
※ 編輯: mrbigmouth 來自: 218.170.60.209 (12/22 22:25)
※ 編輯: mrbigmouth 來自: 218.170.60.209 (12/22 22:34)
※ 引述《TonyQ (自立而後立人。)》之銘言：
: ※ 引述《poopoo888888 (阿川)》之銘言：
: : 大家好
: : 小弟現要撰寫一個網站 功能如下:
: : 這個網站有一個用html table做成的行事曆
: : 所有使用者可以上來看本月的行事曆
^^^^^^^^^^^^^^^^^^^^
: : 也可以新增事項上去
^^^^^^^^^^^^^^^^^^
: : 這樣的功能 需要把資料整理成table易處理的形式
^^^^^^^^^^^^^^^^^
: : 也就是大概要4~5個陣列 每個陣列有7個data
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: : 這樣就可以用迴圈去做出多個<tr>以及其內的<td> 就做出行事曆的樣貌了
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: : 小弟想問的是
: : 整理資料這件事 應該由前端還是後端來做?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: : 用後端做 怕server loading太大
: : 用前端做 怕client端會跑太久
: : 請問各位大大高見?
: : 謝謝!
首先
原Po的問題是「”整理資料”的工作用前端還是後端做會比較好？」
（也就是我上面下標起來的地方）
既然都已經扯到迴圈產tr,td了
可見產出已經是html了
那麼，資料處理前跟處理後的肥大問題我跟TonyQ大大都有共識，
除非這個行事曆只是純粹的<tr><td>完全沒有圖片style等美化元素
不然僅在傳輸的考量上，在前端處理的速度就遠勝在後端處理了
原Po可以看到這裡就好，以下繼續討論我跟TonyQ大大分歧部分
我的觀點是，「除非牽涉到資料安全保密等非後端處理不可的工作
所有工作都應該交給前端處理。」
現在看起來是滿偏頗的，必須加上以下幾個前題，
1.你的主機不是超猛超強外加到處開支散葉的雲端等級
這也是我之前提過的，如果前後端的處理能力實在差異過大，那也不用考慮了
2.在不考慮SEO的狀況下
大家都知道，一扯到javascript，各家搜尋器就無力
只要是前端處理出來的資料搜尋器就找不到，前端0分後端正分完全不用比
（但是原Po既然都已經在考慮要前端還是後端了，那想必沒有此問題）
3.在前面兩個前題之下，使用者需要對資料造成的改變、對同樣原始資料所展現出的不
同格式變化要求越多，前端就越勝後端
還是以行事曆為範例
如果是如TonyQ所說的，需要的行事曆只是一個Read Only的行事曆
那直接做成html平板頁面不就好了？
前端後端語言全都不用，當然最快！
如果你只需要偶爾對資料做出一點點的改變，
比如說此行事曆只有公司老闆可以改變、全部員工全部只能看，
而且也完全不需要搜尋、drill down成一天行事曆、roll up成年行事曆等處理
在這種情況下，你需要的東西其實是Html產生器，一個幫你把資料變成Html頁面的東西
如果這個過程就是TonyQ大大所說的"以特定格式儲存再從伺服端取出"的"後端語言"
那我認輸，至少在這個情況下認輸
因為整個處理過程根本只有一次嘛！當然是給處理能力最好的電腦去做....
但是
如果你的行事曆至少需要多人編輯、依登入者身份可以隨意插入、刪除、變更工作內容
工作內容有分級、分塊、分類，可以drill down跟roll up等等等的時候
（依在下的不幸工作經驗來看，所有一開始看來很簡單的程式在之後八成都會
在老闆/使用者的要求下加東加西，最後變成這種萬能的樣子）
換句話說,資料進出資料庫的頻率很大的時候
前端就遠勝於後端了
為什麼？
因為在工作交由後端處理的情形下，使用者每執行一次此類操作，
伺服器就需要重新從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的時間
使用資料的類別更是跟使用者體驗八竿子打不著關係
只要用熟了就一點麻煩也不會有
當然,無論如何,前端花費的資源永遠只是小case
重點在於後端要傳輸資料的時候
你要輸出json,就一定要先把所有資料存在記憶體裡才能一次轉換
比如要把從DB resource讀出的資料一筆筆全部存進陣列裡...這過程是要吃記憶體的
小量的資料沒感覺,如果是一千筆、一萬筆資料呢?一個留言板的全部文章這種呢?
(特別是當使用語言是PHP陣列這種消費記憶體為實際N倍的怪物時)
從Server輸出CSV就不會有這種問題
json當然好用,我自己寫ajax時也有超過一半是在用json
但json比csv好的優勢在於可以存進多層次、複雜的資料,而不是在效率
然後...從DB撈出來的原始資料,絕大多時候都是CSV能夠處理的
在我上面所說的例子,當後端完全只負責撈DB與傳輸的情形下
完全可以使用CSV取代json,殺雞焉用牛刀
: 直接回文吧，以我的觀點。
: 1.資料的提供應該是主要key是 id 附日期的事件 json 資料
: (server 的責任)
: 怎麼樣我都不會考慮 output csv 的，
: 因為server output json 太方便了，
: 產csv跟產json需要的效能資源相去無幾。
: 真的沒必要再client 再弄一隻 csv parser，
: 找自己麻煩也造成爛使用者體驗。
: 當然 xml 也不是好選擇。
: json 絕對是server提供前端資料的王道。
: 2.至於把這個json資料切成日期格子，日期怎麼呈現，
: 甚至是怎麼上色， 1~31 號怎麼排，這都可以歸在 client做。
: 不過我會歸在 client 做主要是為了增刪方便，操作可以統一都在client，
: 如果需要 AJAX 更新只要統一 call同的 api 就可以直接更新。
: 如果這個table 是 readonly ，也不會要對這個UI做操作，
: 我覺得直接 server side 做掉實際，也可以兼顧SEO議題。
: -----------------------------------
: 當然為了方便client 作業，第一天是星期幾，
: 這種訊息也可以考慮由server提供。
: 這個操作即使在server side ，
: 也可以輕鬆同時上百人，原則上不太會是問題。
: 畢竟只是簡單的字串處理。
: 一般而言，會對 server 造成負擔的
: 主要是 IO 、 service 跟 db 。
: 字串除非你有到幾 MB 的程度，不然都是小咖。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.170.60.209
※ 編輯: mrbigmouth 來自: 218.170.60.209 (12/22 22:07)
※ 編輯: mrbigmouth 來自: 218.170.60.209 (12/22 22:10)