※ 引述《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) ※ 编辑: mrbigmouth 来自: 218.170.60.209 (12/22 22:25) ※ 编辑: mrbigmouth 来自: 218.170.60.209 (12/22 22:34)