JetFang
目前大部分研發團隊都要求業務邏輯用代碼來實現，SQL操作往往都是基本操作。用SQL來表現業務邏輯，也就是通過存儲過程的方式來表現業務邏輯是比較傳統的開發方案。
在C/S時代很多邏輯的實現都是通過SQL來實現的，主要原因是業務規模和部署方式決定的。早期的C/S編程時代往往都是非分佈式環境下的開發，而且大多數情況下並不需要考慮移植性問題，此時採用SQL來完成業務邏輯是比較方便的處理方式。
採用存儲過程來完成業務邏輯最大的好處是性能會比較好，但是這也取決於業務規模的大小，如果業務規模過大，那麼性能會下降的比較厲害。而早期的數據存儲規模比較小，所以採用存儲過程的方式是比較方便的。
目前的Web開發已經到了大數據時代、雲計算時代，業務類型和業務規模都有了較大的變化，尤其是大數據時代下NoSql數據庫的廣泛採用，使用SQL語句來完成業務邏輯的情景就更少了。而且，目前的程序大部分都是分佈式方式，採用Sql存儲過程的方式來處理業務邏輯會非常麻煩，而且會導致整個項目的移植性和可讀性都嚴重下降。
目前在傳統企業的開發團隊中採用Sql來處理業務邏輯的情況比較常見，因為大部分傳統企業的數據庫還依然是關係型數據庫，而且不存在移植性要求，這種固定場景下的開發是完全可以使用Sql來處理業務邏輯的。未來使用Sql處理業務邏輯的情況也有一定的應用場景，所以學習存儲過程的編寫還是有一定必要的。
我的研究方向是大數據和人工智能，目前也在帶大數據方向的研究生，我會陸續在頭條上寫一些關於大數據方面的文章，感興趣的朋友可以關注我的頭條號，相信一定會有所收穫。
如果有大數據方面的問題，也可以諮詢我。
謝謝！
IT人劉俊明
寫在SQL裡面
優勢：
* 性能較高
* 複雜查詢實現起來更直接簡單。
劣勢：
* 數據字段變化，重構麻煩。
* 腳本邏輯太多的時候，維護很麻煩。
* 複用設計更麻煩。
相對的如果通過ORM操作
優勢：
* ORM一般適配了多種關係數據庫，便於切換不同庫（這個在開發階段有可能用）
* 配合緩存使用，設計合理的話速度不會差異太大。
* 更自由地設計服務架構，比如分佈式鎖的使用。
劣勢：
* 出於性能考慮，需要確認最終轉換的SQL是否合理（這個說實話也不算劣勢）。
* 複雜查詢表達能力不如SQL直觀。
一般我會折衷，複雜的統計查詢之類的用存儲過程或者視圖，其它的ORM。有些場合還會搭配Mongodb之類的Nosql。
遷徙的麻雀zzz
第二個更實用，擴展也容易。而且代碼量會比第一種少一半以上。後期性能調優也容易。前提是開發人員必須精通SQL。話說回來SQL不行，全指望orm的人，還是不要做編程這一行了。
第一種用的好了，最多和第二種差不多，弄得不好，會有無數的坑在前面等他們
詩兔
目前能想到的場景裡 只有統計報表系統 部分報表聚合邏輯適合寫在sql中 開發效率較寫在中間層要高 大部分報表可以做到sql查詢所見即所得。但是 要求研發有很強的集合概念 熟悉庫表結構 sql語法 和 各種sql方言
其他場景 例如 各個業務線比入訂單流程 等 數據庫的作用還是迴歸存儲 比較好 其他的邏輯控制等防在中間層比較好
