这问题没有绝对答案,
就是看状况,
但依照你需求,用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哪个做法比较好，会有差异吗？