Re: [討論] SQL的指令優缺點

看板Soft_Job作者 (Terry)時間7年前 (2016/10/18 17:35), 編輯推噓3(3推 0噓 12→)
留言15則, 6人參與, 最新討論串5/5 (看更多)
※ 引述《ripple0129 (perry tsai)》之銘言： : 在看過一些複雜的SQL指令後， : 覺得這是個難以維護的東西。 : 優點自然也是有的， : 可以少寫不少程式碼。 情況1. : 而複雜的SQL指令不外乎Join了好幾個Table， : Where了好幾種條件。 : 想請教各位大大對於SQL的應用上， 情況2. : 單純做CRUD然後給與對應的entity物件， : 需要Join時就是Select Table出來， : 之後再自行用程式碼拼裝。 : 還是下達花式SQL指令降低程式碼量好？ : 然後哪一種對資料庫有較輕的負擔？ 簡單的回答 兩種disk I/O 都一樣。 但 對DB哪台機器來說， 情況1. CPU bound 情況2. network I/O bound 對AP哪台機器來說 情況1. 沒事。 情況2. network I/O bound + CPU bound 資料量（筆數及SIZE）<<<<< network I/O 的負載，都沒差。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 175.184.246.168 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1476783316.A.61B.html
→
10/18 17:39, , 1F
這個解釋好像是最乾淨的
10/18 17:39, 1F
推
10/18 17:41, , 2F
推
10/18 17:41, 2F
推
10/18 18:19, , 3F
　
10/18 18:19, 3F
→
10/18 18:29, , 4F
他的情況1 2不是分別為
10/18 18:29, 4F
→
10/18 18:29, , 5F
1. 單純做CRUD然後給與對應的entity物件，需要Join時就是
10/18 18:29, 5F
→
10/18 18:30, , 6F
Select Table出來，之後再自行用程式碼拼裝。
10/18 18:30, 6F
→
10/18 18:30, , 7F
2. 還是下達花式SQL指令降低程式碼量好
10/18 18:30, 7F
→
10/18 18:30, , 8F
和這篇回覆是的是相同案例嗎? 還是我的眼睛有業障?
10/18 18:30, 8F
→
10/18 18:33, , 9F
問的是要用花式SQL直接取出資料還是將邏輯擺在程式裡
10/18 18:33, 9F
→
10/18 18:56, , 10F
精闢
10/18 18:56, 10F
推
10/20 21:52, , 11F
2要看情況. 目前在做一個需要處理大量散工薪資計算的
10/20 21:52, 11F
→
10/20 21:54, , 12F
系統, 二十來個table十來萬條記錄方能產生一個員工的
10/20 21:54, 12F
→
10/20 21:55, , 13F
薪金計算結果. 丟給AP做這資料量大概會把網路拖死...
10/20 21:55, 13F
→
10/20 21:57, , 14F
當然SQL本身也有不擅長處理的事, 所以最佳解應該是把
10/20 21:57, 14F
→
10/20 21:58, , 15F
資料丟給embed到SQL server的module上跑?
10/20 21:58, 15F
‣ 更多 Lordaeron 的文章
文章代碼(AID): #1O1UpKOR (Soft_Job)
‣ 更多 Lordaeron 的文章
文章代碼(AID): #1O1UpKOR (Soft_Job)