這問題沒有絕對答案,
就是看狀況,
但依照你需求,用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哪個做法比較好，會有差異嗎？