最近萬年議題又被拿出來討論了，「該把程式碼寫在 Stored Procedure，還是寫在 Application 裡面？」
⠀
以下是個人的看法以及選擇，僅供參考。
⠀
我個人的背景是這樣的，都是以開發 Web 應用程式為主，資料庫的使用經驗都在 SQL Server，其他的資料庫領域我不了解，在這樣的背景之下我個人傾向不使用 Stored Procedure 的，原因如下：
⠀
1. 對 DB 的操作已經是在應用程式生命週期的末端，這時候關注的應該是「效能」，如何運用最少的資源（CPU、Memory、Network IO、Disk IO、Money...）最快的速度拿到想要取得的資料，如果把程式碼都寫在 Stored Procedure，為了效能這件事，就會開始在商業邏輯中混入一些 Temp Table、額外定義 Table Type、因效能而使用的特殊語法...等，隨著時間流逝這個 Stored Procedure 就慢慢變成了哥吉拉。
⠀
2. 由於 SQL Server 的改進，Stored Procedure precompiled 的優點早已消失。
(https://www.codeproject.com/Articles/414272/Stored-Procedures-DO-NOT-increase-performance)
⠀
3. 被 Parameter Sniffing 搞得很煩。
⠀
4. 身為那條龍，我為何要將原始碼放在兩個地方？
⠀
雖然我不想使用 Stored Procedure 但不表示可以忽視查詢效能這件事，基本對 Index 的了解、各種 JOIN 差異、查詢計劃的解讀、...等，會影響查詢效能的要略懂，也順便跟還在跟哥吉拉奮戰的朋友說聲辛苦了。
stored procedure優點 在 Re: [討論] SQL的指令優缺點- 看板Soft_Job 的推薦與評價
※ 引述《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 <---(舊架構整合)---> product B ver. 1
改架構後
product A ver. 2 <---(新架構整合)---> product B ver. 2
所以
product A ver. 1 <---(不相容)---> product B ver. 2
product A ver. 2 <---(不相容)---> product B ver. 1
也就是說客戶如果只升級product A，或是只升級product B，就會產生不相容的問題。
這時候聰明的architect都會想出一招
"新舊架構並存"!!!
以後和我們整合都要走新的架構，但是舊的架構要留著，因為客戶已經在用了。
恩，於是程式就更髒了...
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.24.213.99
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1476525620.A.FD3.html
什麼樣的東西應該放到SQL
什麼樣的東西應該放到programming language
其實不太容易界定，也是爭辯不休的問題
我自己是把跟資料操作相關的動作放到SQL，其他的業務邏輯放在放在programming
language
... <看更多>