※ 引述《ripple0129 (perry tsai)》之銘言：
有感而發，分享一下我自己的想法。
: 在看過一些複雜的SQL指令後，
: 覺得這是個難以維護的東西。
: 優點自然也是有的，
: 可以少寫不少程式碼。
: 而複雜的SQL指令不外乎Join了好幾個Table，
: Where了好幾種條件。
: 想請教各位大大對於SQL的應用上，
: 單純做CRUD然後給與對應的entity物件，
: 需要Join時就是Select Table出來，
: 之後再自行用程式碼拼裝。
: 還是下達花式SQL指令降低程式碼量好？
看到複雜的SQL就覺得難以維護通常有幾個原因：
1. 你SQL功力太差
2. 當初寫這段SQL的人功力太差
3. 真的很複雜
如果看到複雜的SQL就覺得應該盡量搬到programming language來處理，其實是矯枉過正啦
之所以會覺得SQL複雜是因為
1. 寫SQL的思維和寫programming language不一樣
2. SQL雖然已經有TRY-CATCH、迴圈，條件判斷...等等功能，
但是畢竟它不像一般programming language一樣成熟。
(programming language有framewrok可以用，有class、template、封裝繼承多型..等
可以你在寫程式的時候盡量地code reuse)
很多對SQL不熟的人把一些業務邏輯寫到stored procedure裡面來，
SQL code自然變得又臭又長。
(曾經看過上千行的stored procedure，實在讓人不想維護)
3. 很多公司傾向不找"只懂SQL，但是對SQL非常專精的expert"
: 然後哪一種對資料庫有較輕的負擔？
: 反正規化的查詢速度優勢，
: 犧牲了正規後儲存空間以及降低了資料一致性，
: 且對於程式碼來說也降低維護性，
: 在現今環境來說值得嗎？
: 我個人的看法是維護性最高優先權，
: 在維護性低的情形下，
: 後面加入的程式碼品質可能每況愈下。
: 程式碼品質不斷降低會造成資料庫的損耗加重。
: 最後可能得不償失。
: 想了解我這樣的觀念是錯誤的嗎？
因為你是engineer，每天看程式，如果程式很髒你會很痛苦，
所以才會覺得維護性優先權最高。
如果你是PM，就不會覺得維護性的優先權最高。
優先權最高的是要能夠賣錢，
要能夠賣錢就要來看你提供的features是不是客戶想要的，
再來是performance的問題，因為用起來很慢的話，客戶會不爽，
最後才是維護性的問題。
如果你產品的賣不了錢，很快地整個project就會死了，所以也不需要維護了。
但是話說回來，這也是為什麼程式會很髒的原因之一，
因為一些methodology都會希望你趕快把產品拿到市場上去做驗證，
收集feedback之後，回來再做改進。
所以開發的時候總是把"在限定時間內，把features做出來"放在最優先。
至於code髒不髒那不是最重要的事情。反正之後再改就好。
其實程式髒還不是最可怕的，可怕的是架構髒。
程式髒還不難改。架構髒的話你想改也改不動，因為一改幾乎就是整個重寫。
更可怕的是有些架構就算你想重寫也不行，因為已經和其他產品整合在一起，
你一改代表其他產品部門也要跟著改，其他產品部門你很難叫得動。
最可怕的如果你的產品是需要release到客戶端的
萬一舊的架構客戶已經在用了，一旦新架構release出去，
客戶要同時升級2個產品，不然會fail。比方說：
product A ver. 1 <