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

看板Soft_Job作者 (東周流浪漢)時間7年前 (2018/09/18 10:47), 編輯推噓9(9推 0噓 36→)
留言45則, 11人參與, 7年前最新討論串2/2 (看更多)
這問題沒有絕對答案, 就是看狀況, 但依照你需求,用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
推
09/18 12:11, 7年前 , 1F
感謝大大分享～ DB博大精深 Orz
09/18 12:11, 1F
推
09/18 13:19, 7年前 , 2F
推看資料"量"以及是否具有即時性，B的做法也可以做成VIEW
09/18 13:19, 2F
→
09/18 13:19, 7年前 , 3F
要用再去query view 就好了，A的話基本就像是API
09/18 13:19, 3F
→
09/18 13:20, 7年前 , 4F
如果資料都不是陣列結構那A比較好我覺得。乾淨，簡單
09/18 13:20, 4F
→
09/18 13:20, 7年前 , 5F
RESTFUL
09/18 13:20, 5F
推
09/18 13:24, 7年前 , 6F
想請問sp是什麼意思 謝謝
09/18 13:24, 6F
推
09/18 13:39, 7年前 , 7F
stored procedure
09/18 13:39, 7F
→
09/18 13:41, 7年前 , 8F
這東西雖然方便，但我覺得不好，尤其是版控
09/18 13:41, 8F
→
09/18 14:15, 7年前 , 9F
sp版控用的挺順的 跟一般程式無異 樓上覺得不好的點在哪@
09/18 14:15, 9F
→
09/18 14:15, 7年前 , 10F
@
09/18 14:15, 10F
推
09/18 14:55, 7年前 , 11F
推～我沒用過sp，剛剛查了一下感覺是把常用的DB語法封裝
09/18 14:55, 11F
→
09/18 14:56, 7年前 , 12F
，方便重複使用這樣嗎？
09/18 14:56, 12F
→
09/18 15:07, 7年前 , 13F
Sp就是存在db的程式物件呀 可以想成是有邏輯判斷的sql
09/18 15:07, 13F
推
09/18 15:43, 7年前 , 14F
SP 近似於 OOP 的方法
09/18 15:43, 14F
→
09/18 15:43, 7年前 , 15F
view的做法我也有想到，但原po還不會用子查詢，用view
09/18 15:43, 15F
→
09/18 15:43, 7年前 , 16F
好像跳太快
09/18 15:43, 16F
→
09/18 15:45, 7年前 , 17F
正常應該是要先會寫子查詢，然後再把子查詢寫成view
09/18 15:45, 17F
推
09/18 15:47, 7年前 , 18F
對喔~~當子查詢的join要變成一團糨糊的時候還是弄VIEW好
09/18 15:47, 18F
→
09/18 15:47, 7年前 , 19F
如果只有一個地方用到的話，特地寫個view好像沒必要，
09/18 15:47, 19F
→
09/18 15:47, 7年前 , 20F
view並不會增加查詢速度
09/18 15:47, 20F
→
09/18 15:48, 7年前 , 21F
我是考量到看資料的頻率或是有沒有要即時更新
09/18 15:48, 21F
→
09/18 15:48, 7年前 , 22F
但是這個是在功能設計的時候的事情
09/18 15:48, 22F
→
09/18 15:49, 7年前 , 23F
之前是比較常用的頻率不高但是要join多張的就放view
09/18 15:49, 23F
→
09/18 15:49, 7年前 , 24F
然後另外寫一個sp去照時間更新view
09/18 15:49, 24F
→
09/18 15:58, 7年前 , 25F
這樣的話要注意效能，多張表合成的view容易變慢，若表
09/18 15:58, 25F
→
09/18 15:58, 7年前 , 26F
的數據量都不大的是還好，而且view本身無法下where，
09/18 15:58, 26F
→
09/18 15:58, 7年前 , 27F
等於一查就是查所有表的全表了，可以考慮用表函數解決
09/18 15:58, 27F
→
09/18 18:32, 7年前 , 28F
表函數可下條件 但對原po應該是還不太能駕馭
09/18 18:32, 28F
→
09/18 18:33, 7年前 , 29F
Vein 串出來 能再對view下條件也是可以
09/18 18:33, 29F
→
09/18 18:34, 7年前 , 30F
View
09/18 18:34, 30F
→
09/18 18:46, 7年前 , 31F
所以ㄚ，我們講了一大堆技術有什麼用？乾脆讓原po先用
09/18 18:46, 31F
→
09/18 18:46, 7年前 , 32F
自己最熟的方式處理，之後他就會慢慢了解了，經驗就是
09/18 18:46, 32F
→
09/18 18:46, 7年前 , 33F
這樣磨出來的
09/18 18:46, 33F
推
09/18 22:14, 7年前 , 34F
不用管原PO啊XD 這樣的討論內容本身很有價值呢
09/18 22:14, 34F
→
09/18 22:35, 7年前 , 35F
我覺得弄一堆子查詢跟case就只為了能一次到位，可讀
09/18 22:35, 35F
→
09/18 22:35, 7年前 , 36F
性跟維護性會變很差耶
09/18 22:35, 36F
→
09/18 22:40, 7年前 , 37F
另外我也想問，如果遇到只能tablescan，是直接讓sql
09/18 22:40, 37F
→
09/18 22:40, 7年前 , 38F
解決，還是撈出來再用程式篩會比較快？
09/18 22:40, 38F
推
09/18 22:43, 7年前 , 39F
推這篇~專業分析
09/18 22:43, 39F
→
09/18 23:15, 7年前 , 40F
理論上是撈出來比會比較快，但因為網路問題很難快速的
09/18 23:15, 40F
→
09/18 23:15, 7年前 , 41F
傳大量資料，所以還是用sql查比較好
09/18 23:15, 41F
→
09/18 23:18, 7年前 , 42F
可能我比較習慣sql,也有工具可以排版，倒不覺得子查詢
09/18 23:18, 42F
→
09/18 23:18, 7年前 , 43F
會比一般程式難維護
09/18 23:18, 43F
→
09/18 23:28, 7年前 , 44F
了解~ 感謝
09/18 23:28, 44F
→
09/19 00:06, 7年前 , 45F
只SELECT必要的欄位,可讀性不會差到哪
09/19 00:06, 45F
‣ 更多 littlethe 的文章
文章代碼(AID): #1Re6TT3Q (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 2 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共2篇)
‣ 更多 littlethe 的文章
文章代碼(AID): #1Re6TT3Q (Soft_Job)