JetFang
個人建議，普通的業務邏輯儘量寫在後臺代碼中，儘量避免寫在SQL中，並且儘量避免使用存儲過程。
不可否認將業務邏輯寫在SQL或存儲過程中，也是有這種做法的優點，比如：可以減少網絡交互的成本，原本後臺程序需要多次訪問數據庫，現在可以用複雜的SQL或者存儲過程封裝好，然後程序調用一次即可。
但是複雜SQL和存儲過程也有很大的缺點：
不可移植性，每種數據庫的語法多多少少都會有一些差異；如果SQL中使用到數據的一些函數、方法，而這些又是該數據獨有的，那麼很難做數據庫的遷移。
業務邏輯會存在SQL和程序中，這種業務邏輯多處存在，會讓後期的系統維護和調試都變得更加困難。
數據庫中所支持的函數及語法不一定可以滿足所有的需求，相比來說，編程語言中的功能更加的強大。
如果SQL、存儲過程中有複雜的計算，也會增加數據庫機器的壓力；並且很難做到分佈式部署。
相比編程語言，業務邏輯寫在SQL、存儲過程中，很難做到業務邏輯的抽象，所以從代碼複用的角度來看，編程語言更勝一籌。
所以，普通業務邏輯儘量不要使用複雜SQL或存儲過程，而如果是報表統計或者ETL抽取等功能，可以根據實際的情況，採用複雜SQL或者存儲過程來處理。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
目前大部分研發團隊都要求業務邏輯用代碼來實現，SQL操作往往都是基本操作。用SQL來表現業務邏輯，也就是通過存儲過程的方式來表現業務邏輯是比較傳統的開發方案。
在C/S時代很多邏輯的實現都是通過SQL來實現的，主要原因是業務規模和部署方式決定的。早期的C/S編程時代往往都是非分佈式環境下的開發，而且大多數情況下並不需要考慮移植性問題，此時採用SQL來完成業務邏輯是比較方便的處理方式。
採用存儲過程來完成業務邏輯最大的好處是性能會比較好，但是這也取決於業務規模的大小，如果業務規模過大，那麼性能會下降的比較厲害。而早期的數據存儲規模比較小，所以採用存儲過程的方式是比較方便的。
目前的Web開發已經到了大數據時代、雲計算時代，業務類型和業務規模都有了較大的變化，尤其是大數據時代下NoSql數據庫的廣泛採用，使用SQL語句來完成業務邏輯的情景就更少了。而且，目前的程序大部分都是分佈式方式，採用Sql存儲過程的方式來處理業務邏輯會非常麻煩，而且會導致整個項目的移植性和可讀性都嚴重下降。
目前在傳統企業的開發團隊中採用Sql來處理業務邏輯的情況比較常見，因為大部分傳統企業的數據庫還依然是關係型數據庫，而且不存在移植性要求，這種固定場景下的開發是完全可以使用Sql來處理業務邏輯的。未來使用Sql處理業務邏輯的情況也有一定的應用場景，所以學習存儲過程的編寫還是有一定必要的。
我的研究方向是大數據和人工智能，目前也在帶大數據方向的研究生，我會陸續在頭條上寫一些關於大數據方面的文章，感興趣的朋友可以關注我的頭條號，相信一定會有所收穫。
如果有大數據方面的問題，也可以諮詢我。
謝謝！
IT人劉俊明
第二個更實用，擴展也容易。而且代碼量會比第一種少一半以上。後期性能調優也容易。前提是開發人員必須精通SQL。話說回來SQL不行，全指望orm的人，還是不要做編程這一行了。
第一種用的好了，最多和第二種差不多，弄得不好，會有無數的坑在前面等他們
詩兔
SQL做些基本操作就可以了，業務判斷還是要在代碼中實現，但在做報表的時候，按照在代碼中用增刪改查來操作，會存在大量的查詢和更新，這是極其耗時的，應該儘可能用一條SQL去完成，同時還要注意性能優化。
幽_紅林
目前能想到的場景裡 只有統計報表系統 部分報表聚合邏輯適合寫在sql中 開發效率較寫在中間層要高 大部分報表可以做到sql查詢所見即所得。但是 要求研發有很強的集合概念 熟悉庫表結構 sql語法 和 各種sql方言
其他場景 例如 各個業務線比入訂單流程 等 數據庫的作用還是迴歸存儲 比較好 其他的邏輯控制等防在中間層比較好
豆腐506
關於這個問題應該分場景，不能一概而論。中小項目推薦使用存儲過程解決大部分業務，代碼量少，方便維護。大型項目涉及到分佈式，緩存等等，考慮到數據庫的開銷就不建議太過依託數據庫處理了，因為大併發下數據庫處理複雜業務根本處理不過來。
海涵劉葉城
如果是小項目，業務層寫在存儲過程中也無妨，如果是大型項目，勸你還是封裝起來寫代碼裡，假設大型項目的業務層寫在存儲過程中，拋開性能不說，後期維護起來豪不誇張的說就三個字:要你命
噓表___吵
寫在SQL上的業務，數據一致性強，並且簡化很多。但不好的一點就是數據庫不容易做負載均衡，跑起來有壓力。
至亮時刻
根據項目組的特點來。
如果團隊健康，寫在代碼中。
如果團隊不健康，大部分是剛參加工作的，那就寫在sql中，經驗者維護。
