作者littlethe (东周流浪汉)
看板Soft_Job
标题Re: [请益] 一页的db query数
时间Tue Sep 18 10:47:40 2018
这问题没有绝对答案,
就是看状况,
但依照你需求,用A比较好,
主要原因是因为你对SQL没那麽熟,
所以就用你熟悉的方式处理就好,
以效能来说,是A会比较好,因为运算就不用在DB处理,可以减轻DB的负担,
但以维护性和安全性来说,是B比较好,
但是这有个前提,是要写成SP处理才有意义,
因为维护和安全是靠SP控制,然後外面不能自由下SQL进来,
如果你是直接在应用中下SQL去DB读的话,那就完全没维护性和安全性可言了,
从你描述来看,相信你是直接下SQL的,所以可以不用考虑B了,
另外,照你描述,你要的表若用SQL写的话,可以用子查询完成,
去google一下子查询吧,那很简单很好用的
很多人会觉得B的好处是减少封包,
说实话,若一页1次query和一页2次query的话,
是感觉不太出差别,
除非有天兵一页的每一行都下query,一页搞个50次query那就有差别了...
还真的见过有人这麽干,
如果是B2C或C2C的系统,同时间会有几万人在用的话,
那当然还是尽量一页1个query就好,但这种状况应该要有特殊机制处理效能问题
对於SQL熟练的人来说,B的最大好处反而是开发快速,
你要的表,SQL熟练的人10分钟内就可以写出SQL来,
然後照结果"印"在页面就好了,
用其他程式写的话,还要写回圈,不像SQL下个group by就好
另一个考量就是这个功能会不会在多个地方使用到?
例如这系统有网站和APP,
在网站和APP有出现一模一样的查询,
这种状况下,就是要把SQL写成SP,然後给网站和APP使用,
这样的话,只要改SP,网站和APP就两边都会改到,
如果是用A方法来做的话,那你不就要网站做一次,APP又要再做一次?
APP改还很麻烦,因为要更新版本
所以这问题没有绝对答案,
要看目的,看运算量,看安全性要求,看使用状况,开发时间,对技术的熟悉度
这两种都有自己的优缺点的,
这也是考量一位工程师思考能力的时候,
但也建议和主管聊一下要采用那种方式比较好,
说不定主管有他想法,毕竟什麽东西要写在什麽地方,
是会影响系统结构的,
如果主管让你决定的话,你就用A吧
※ 引述《asleepme (500年没换昵称了)》之铭言：
: 想请教一下，读取一页的时候 db 的query 次数会是一个重要的考量吗？
: 效能、维护性、安全性等等
: db server跟app server是不同主机，每个query也不复杂
: 假设有2个做法
: A. 透过3-4个query，table 拉回来的资料就是可以直接用的
: B. 把多个table join成一个query，一次把资料拉回来
: 然後程式逻辑需要在处理一下，这个程式逻辑也不复杂
: A跟B哪个做法比较好，会有差异吗？
--
一个公司好不好,看资料库就知道
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 59.63.207.90
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1537238877.A.0DA.html
1F：推 asleepme: 感谢大大分享～ DB博大精深 Orz 09/18 12:11
2F：推 neo5277: 推看资料"量"以及是否具有即时性，B的做法也可以做成VIEW 09/18 13:19
3F：→ neo5277: 要用再去query view 就好了，A的话基本就像是API 09/18 13:19
4F：→ neo5277: 如果资料都不是阵列结构那A比较好我觉得。乾净，简单 09/18 13:20
5F：→ neo5277: RESTFUL 09/18 13:20
6F：推 TuCH: 想请问sp是什麽意思 谢谢 09/18 13:24
7F：推 jack0204: stored procedure 09/18 13:39
8F：→ jack0204: 这东西虽然方便，但我觉得不好，尤其是版控 09/18 13:41
9F：→ MixBear: sp版控用的挺顺的 跟一般程式无异 楼上觉得不好的点在哪@ 09/18 14:15
10F：→ MixBear: @ 09/18 14:15
11F：推 DCTmaybe: 推～我没用过sp，刚刚查了一下感觉是把常用的DB语法封装 09/18 14:55
12F：→ DCTmaybe: ，方便重复使用这样吗？ 09/18 14:56
13F：→ keyboard56: Sp就是存在db的程式物件呀 可以想成是有逻辑判断的sql 09/18 15:07
14F：推 neo5277: SP 近似於 OOP 的方法 09/18 15:43
15F：→ littlethe: view的做法我也有想到，但原po还不会用子查询，用view 09/18 15:43
16F：→ littlethe: 好像跳太快 09/18 15:43
17F：→ littlethe: 正常应该是要先会写子查询，然後再把子查询写成view 09/18 15:45
18F：推 neo5277: 对喔~~当子查询的join要变成一团糨糊的时候还是弄VIEW好 09/18 15:47
19F：→ littlethe: 如果只有一个地方用到的话，特地写个view好像没必要， 09/18 15:47
20F：→ littlethe: view并不会增加查询速度 09/18 15:47
21F：→ neo5277: 我是考量到看资料的频率或是有没有要即时更新 09/18 15:48
22F：→ neo5277: 但是这个是在功能设计的时候的事情 09/18 15:48
23F：→ neo5277: 之前是比较常用的频率不高但是要join多张的就放view 09/18 15:49
24F：→ neo5277: 然後另外写一个sp去照时间更新view 09/18 15:49
25F：→ littlethe: 这样的话要注意效能，多张表合成的view容易变慢，若表 09/18 15:58
26F：→ littlethe: 的数据量都不大的是还好，而且view本身无法下where， 09/18 15:58
27F：→ littlethe: 等於一查就是查所有表的全表了，可以考虑用表函数解决 09/18 15:58
28F：→ keyboard56: 表函数可下条件 但对原po应该是还不太能驾驭 09/18 18:32
29F：→ keyboard56: Vein 串出来 能再对view下条件也是可以 09/18 18:33
30F：→ keyboard56: View 09/18 18:34
31F：→ littlethe: 所以ㄚ，我们讲了一大堆技术有什麽用？乾脆让原po先用 09/18 18:46
32F：→ littlethe: 自己最熟的方式处理，之後他就会慢慢了解了，经验就是 09/18 18:46
33F：→ littlethe: 这样磨出来的 09/18 18:46
34F：推 asleepme: 不用管原PO啊XD 这样的讨论内容本身很有价值呢 09/18 22:14
35F：→ lazarus1121: 我觉得弄一堆子查询跟case就只为了能一次到位，可读 09/18 22:35
36F：→ lazarus1121: 性跟维护性会变很差耶 09/18 22:35
37F：→ lazarus1121: 另外我也想问，如果遇到只能tablescan，是直接让sql 09/18 22:40
38F：→ lazarus1121: 解决，还是捞出来再用程式筛会比较快？ 09/18 22:40
39F：推 viper9709: 推这篇~专业分析 09/18 22:43
40F：→ littlethe: 理论上是捞出来比会比较快，但因为网路问题很难快速的 09/18 23:15
41F：→ littlethe: 传大量资料，所以还是用sql查比较好 09/18 23:15
42F：→ littlethe: 可能我比较习惯sql,也有工具可以排版，倒不觉得子查询 09/18 23:18
43F：→ littlethe: 会比一般程式难维护 09/18 23:18
44F：→ lazarus1121: 了解~ 感谢 09/18 23:28
45F：→ ChungLi5566: 只SELECT必要的栏位,可读性不会差到哪 09/19 00:06