為什麼這篇輕推理論壞處鄉民發文收入到精華區：因為在輕推理論壞處這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者ripple0129 (perry tsai)看板Soft_Job標題[討論] SQL的指令優缺...
在看過一些複雜的SQL指令後，
覺得這是個難以維護的東西。
優點自然也是有的，
可以少寫不少程式碼。
而複雜的SQL指令不外乎Join了好幾個Table，
Where了好幾種條件。
想請教各位大大對於SQL的應用上，
單純做CRUD然後給與對應的entity物件，
需要Join時就是Select Table出來，
之後再自行用程式碼拼裝。
還是下達花式SQL指令降低程式碼量好？
然後哪一種對資料庫有較輕的負擔？
反正規化的查詢速度優勢，
犧牲了正規後儲存空間以及降低了資料一致性，
且對於程式碼來說也降低維護性，
在現今環境來說值得嗎？
我個人的看法是維護性最高優先權，
在維護性低的情形下，
後面加入的程式碼品質可能每況愈下。
程式碼品質不斷降低會造成資料庫的損耗加重。
最後可能得不償失。
想了解我這樣的觀念是錯誤的嗎？
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.136.10.154
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1476469261.A.E77.html
→ pttworld: 第一問題要看使用的framework。 10/15 02:28
→ pttworld: 第二問題是文件做好則沒有一定。 10/15 02:28
→ pttworld: 第三問題相關性小。擴充時能否維持前人的程式品質。 10/15 02:30
→ ChungLi5566: 全部撈回來才篩 太慢了又浪費頻寬 10/15 08:07
推 bobju: 理論上跟實務上經常要有所取捨。你說的問題的確有，怎麼做 10/15 09:06
→ bobju: 則視個案而定。 10/15 09:06
→ travelerX: 先where 篩選, 不join 大表 , 需要join大表時拆成兩次 10/15 09:08
→ travelerX: 查詢，再用程式比對會快很多（上次看到一個1xx萬筆資料 10/15 09:09
→ travelerX: table join 1xx萬筆資料再where的要跑12秒） 10/15 09:09
推 yyc1217: 兩種狀況都遇過 看專案 沒有一定答案 10/15 10:37
推 Masakiad: 除非明顯的可以看出差距不然開發當下以好維護為主 10/15 10:40
推 Masakiad: 所以通常都等出現瓶頸在抓比較符合現實狀況，有的功能 10/15 10:42
→ Masakiad: 根本一輩子不會出現瓶頸，不用擔心太早... 10/15 10:42
推 johnlinvc: 用會幫你join 的 framework 10/15 11:44
→ cd99cd99: 算成本 10/15 12:17
→ xdraculax: 花式SQL主要目的不是減少程式碼，是求效能 10/16 06:28
→ xdraculax: 會覺得不好維護那是你對 framework 比對 SQL 熟 10/16 06:30
→ xdraculax: 相反的對 SQL 比對 framework 熟的就覺得拆開抓到程式 10/16 06:31
→ xdraculax: 中併比較難維護 10/16 06:31
→ xdraculax: SQL也能作到先篩選再join，夠熟SQL能作到許多framework 10/16 06:34
→ xdraculax: 作不到的事 10/16 06:34
推 mathrew: 算成本 10/16 21:04