Re: [請益] 一頁的db query數

[littlethe (東周流浪漢)]

這問題沒有絕對答案,

就是看狀況,

但依照你需求,用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://www.ptt.cc/bbs/Soft_Job/M.1537238877.A.0DA.html
推 asleepme: 感謝大大分享～ DB博大精深 Orz
推 neo5277: 推看資料"量"以及是否具有即時性，B的做法也可以做成VIEW
→ neo5277: 要用再去query view 就好了，A的話基本就像是API
→ neo5277: 如果資料都不是陣列結構那A比較好我覺得。乾淨，簡單
→ neo5277: RESTFUL
推 TuCH: 想請問sp是什麼意思 謝謝
推 jack0204: stored procedure
→ jack0204: 這東西雖然方便，但我覺得不好，尤其是版控
→ MixBear: sp版控用的挺順的 跟一般程式無異 樓上覺得不好的點在哪@
→ MixBear: @
推 DCTmaybe: 推～我沒用過sp，剛剛查了一下感覺是把常用的DB語法封裝
→ DCTmaybe: ，方便重複使用這樣嗎？
→ keyboard56: Sp就是存在db的程式物件呀 可以想成是有邏輯判斷的sql
推 neo5277: SP 近似於 OOP 的方法
→ littlethe: view的做法我也有想到，但原po還不會用子查詢，用view
→ littlethe: 好像跳太快
→ littlethe: 正常應該是要先會寫子查詢，然後再把子查詢寫成view
推 neo5277: 對喔~~當子查詢的join要變成一團糨糊的時候還是弄VIEW好
→ littlethe: 如果只有一個地方用到的話，特地寫個view好像沒必要，
→ littlethe: view並不會增加查詢速度
→ neo5277: 我是考量到看資料的頻率或是有沒有要即時更新
→ neo5277: 但是這個是在功能設計的時候的事情
→ neo5277: 之前是比較常用的頻率不高但是要join多張的就放view
→ neo5277: 然後另外寫一個sp去照時間更新view
→ littlethe: 這樣的話要注意效能，多張表合成的view容易變慢，若表
→ littlethe: 的數據量都不大的是還好，而且view本身無法下where，
→ littlethe: 等於一查就是查所有表的全表了，可以考慮用表函數解決
→ keyboard56: 表函數可下條件 但對原po應該是還不太能駕馭
→ keyboard56: Vein 串出來 能再對view下條件也是可以
→ keyboard56: View
→ littlethe: 所以ㄚ，我們講了一大堆技術有什麼用？乾脆讓原po先用
→ littlethe: 自己最熟的方式處理，之後他就會慢慢了解了，經驗就是
→ littlethe: 這樣磨出來的
推 asleepme: 不用管原PO啊XD 這樣的討論內容本身很有價值呢
→ lazarus1121: 我覺得弄一堆子查詢跟case就只為了能一次到位，可讀
→ lazarus1121: 性跟維護性會變很差耶
→ lazarus1121: 另外我也想問，如果遇到只能tablescan，是直接讓sql
→ lazarus1121: 解決，還是撈出來再用程式篩會比較快？
推 viper9709: 推這篇~專業分析
→ littlethe: 理論上是撈出來比會比較快，但因為網路問題很難快速的
→ littlethe: 傳大量資料，所以還是用sql查比較好
→ littlethe: 可能我比較習慣sql,也有工具可以排版，倒不覺得子查詢
→ littlethe: 會比一般程式難維護
→ lazarus1121: 了解~ 感謝
→ ChungLi5566: 只SELECT必要的欄位,可讀性不會差到哪