[討論] SQL的指令優缺點

[ripple0129 (perry tsai)]

在看過一些複雜的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。
→ pttworld: 第二問題是文件做好則沒有一定。
→ pttworld: 第三問題相關性小。擴充時能否維持前人的程式品質。
→ ChungLi5566: 全部撈回來才篩 太慢了又浪費頻寬
推 bobju: 理論上跟實務上經常要有所取捨。你說的問題的確有，怎麼做
→ bobju: 則視個案而定。
→ travelerX: 先where 篩選, 不join 大表 , 需要join大表時拆成兩次
→ travelerX: 查詢，再用程式比對會快很多（上次看到一個1xx萬筆資料
→ travelerX:  table join  1xx萬筆資料再where的要跑12秒）
推 yyc1217: 兩種狀況都遇過 看專案 沒有一定答案
推 Masakiad: 除非明顯的可以看出差距不然開發當下以好維護為主
推 Masakiad: 所以通常都等出現瓶頸在抓比較符合現實狀況，有的功能
→ Masakiad: 根本一輩子不會出現瓶頸，不用擔心太早...
推 johnlinvc: 用會幫你join 的 framework
→ cd99cd99: 算成本
→ xdraculax: 花式SQL主要目的不是減少程式碼，是求效能
→ xdraculax: 會覺得不好維護那是你對 framework 比對 SQL 熟
→ xdraculax: 相反的對 SQL 比對 framework 熟的就覺得拆開抓到程式
→ xdraculax: 中併比較難維護
→ xdraculax: SQL也能作到先篩選再join，夠熟SQL能作到許多framework
→ xdraculax: 作不到的事
推 mathrew: 算成本