在看過一些複雜的SQL指令後，
覺得這是個難以維護的東西。
優點自然也是有的，
可以少寫不少程式碼。
而複雜的SQL指令不外乎Join了好幾個Table，
Where了好幾種條件。
想請教各位大大對於SQL的應用上，
單純做CRUD然後給與對應的entity物件，
需要Join時就是Select Table出來，
之後再自行用程式碼拼裝。
還是下達花式SQL指令降低程式碼量好？
然後哪一種對資料庫有較輕的負擔？
反正規化的查詢速度優勢，
犧牲了正規後儲存空間以及降低了資料一致性，
且對於程式碼來說也降低維護性，
在現今環境來說值得嗎？
我個人的看法是維護性最高優先權，
在維護性低的情形下，
後面加入的程式碼品質可能每況愈下。
程式碼品質不斷降低會造成資料庫的損耗加重。
最後可能得不償失。
想了解我這樣的觀念是錯誤的嗎？

第一問題要看使用的framework。第二問題是文件做好則沒有一定。第三問題相關性小。擴充時能否維持前人的程式品質。

全部撈回來才篩 太慢了又浪費頻寬

理論上跟實務上經常要有所取捨。你說的問題的確有，怎麼做則視個案而定。

先where 篩選, 不join 大表 , 需要join大表時拆成兩次查詢，再用程式比對會快很多（上次看到一個1xx萬筆資料table join 1xx萬筆資料再where的要跑12秒）

兩種狀況都遇過 看專案 沒有一定答案

除非明顯的可以看出差距不然開發當下以好維護為主所以通常都等出現瓶頸在抓比較符合現實狀況，有的功能根本一輩子不會出現瓶頸，不用擔心太早...

用會幫你join 的 framework

算成本

花式SQL主要目的不是減少程式碼，是求效能會覺得不好維護那是你對 framework 比對 SQL 熟相反的對 SQL 比對 framework 熟的就覺得拆開抓到程式中併比較難維護SQL也能作到先篩選再join，夠熟SQL能作到許多framework作不到的事

算成本