第二個更實用，擴充套件也容易。而且程式碼量會比第一種少一半以上。後期效能調優也容易。前提是開發人員必須精通SQL。話說回來SQL不行，全指望orm的人，還是不要做程式設計這一行了。

第一種用的好了，最多和第二種差不多，弄得不好，會有無數的坑在前面等他們

目前大部分研發團隊都要求業務邏輯用程式碼來實現，SQL操作往往都是基本操作。用SQL來表現業務邏輯，也就是透過儲存過程的方式來表現業務邏輯是比較傳統的開發方案。

在C/S時代很多邏輯的實現都是透過SQL來實現的，主要原因是業務規模和部署方式決定的。早期的C/S程式設計時代往往都是非分散式環境下的開發，而且大多數情況下並不需要考慮移植性問題，此時採用SQL來完成業務邏輯是比較方便的處理方式。

採用儲存過程來完成業務邏輯最大的好處是效能會比較好，但是這也取決於業務規模的大小，如果業務規模過大，那麼效能會下降的比較厲害。而早期的資料儲存規模比較小，所以採用儲存過程的方式是比較方便的。

目前的Web開發已經到了大資料時代、雲計算時代，業務型別和業務規模都有了較大的變化，尤其是大資料時代下NoSql資料庫的廣泛採用，使用SQL語句來完成業務邏輯的情景就更少了。而且，目前的程式大部分都是分散式方式，採用Sql儲存過程的方式來處理業務邏輯會非常麻煩，而且會導致整個專案的移植性和可讀性都嚴重下降。

目前在傳統企業的開發團隊中採用Sql來處理業務邏輯的情況比較常見，因為大部分傳統企業的資料庫還依然是關係型資料庫，而且不存在移植性要求，這種固定場景下的開發是完全可以使用Sql來處理業務邏輯的。未來使用Sql處理業務邏輯的情況也有一定的應用場景，所以學習儲存過程的編寫還是有一定必要的。

如果有大資料方面的問題，也可以諮詢我。

目前能想到的場景裡 只有統計報表系統 部分報表聚合邏輯適合寫在sql中 開發效率較寫在中間層要高 大部分報表可以做到sql查詢所見即所得。但是 要求研發有很強的集合概念 熟悉庫表結構 sql語法 和 各種sql方言

其他場景 例如 各個業務線比入訂單流程 等 資料庫的作用還是迴歸儲存 比較好 其他的邏輯控制等防在中間層比較好

如果是小專案，業務層寫在儲存過程中也無妨，如果是大型專案，勸你還是封裝起來寫程式碼裡，假設大型專案的業務層寫在儲存過程中，拋開效能不說，後期維護起來豪不誇張的說就三個字:要你命

關於這個問題應該分場景，不能一概而論。中小專案推薦使用儲存過程解決大部分業務，程式碼量少，方便維護。大型專案涉及到分散式，快取等等，考慮到資料庫的開銷就不建議太過依託資料庫處理了，因為大併發下資料庫處理複雜業務根本處理不過來。

不可否認將業務邏輯寫在SQL或儲存過程中，也是有這種做法的優點，比如：可以減少網路互動的成本，原本後臺程式需要多次訪問資料庫，現在可以用複雜的SQL或者儲存過程封裝好，然後程式呼叫一次即可。

但是複雜SQL和儲存過程也有很大的缺點：

不可移植性，每種資料庫的語法多多少少都會有一些差異；如果SQL中使用到資料的一些函式、方法，而這些又是該資料獨有的，那麼很難做資料庫的遷移。

業務邏輯會存在SQL和程式中，這種業務邏輯多處存在，會讓後期的系統維護和除錯都變得更加困難。

資料庫中所支援的函式及語法不一定可以滿足所有的需求，相比來說，程式語言中的功能更加的強大。

如果SQL、儲存過程中有複雜的計算，也會增加資料庫機器的壓力；並且很難做到分散式部署。

相比程式語言，業務邏輯寫在SQL、儲存過程中，很難做到業務邏輯的抽象，所以從程式碼複用的角度來看，程式語言更勝一籌。

所以，普通業務邏輯儘量不要使用複雜SQL或儲存過程，而如果是報表統計或者ETL抽取等功能，可以根據實際的情況，採用複雜SQL或者儲存過程來處理。

根據專案組的特點來。

如果團隊健康，寫在程式碼中。

如果團隊不健康，大部分是剛參加工作的，那就寫在sql中，經驗者維護。

SQL做些基本操作就可以了，業務判斷還是要在程式碼中實現，但在做報表的時候，按照在程式碼中用增刪改查來操作，會存在大量的查詢和更新，這是極其耗時的，應該儘可能用一條SQL去完成，同時還要注意效能最佳化。

早期CS架構開發，主要針對企業應用，S端就是資料庫端，那時幾乎所有的業務都是在儲存過程中完成，為什麼？因為資料庫伺服器足夠強勁，動輒上千萬的小型機，想想那時候Oracle的風光。

但隨著web的興起，BS開發架構逐漸成為主流，這裡的S已經不侷限於資料庫服務，特別是三層及多層架構的普及後，業務實現的重心已經遷移到web伺服器中，為什麼？因為資料庫服務已經不能承載面向全球百萬級甚至億級使用者請求的計算壓力。唯一的解決辦法就是分散式的叢集方案，算力不夠，伺服器來湊，不買效能強勁的昂貴的伺服器，轉而購買巨大數量的價效比高的廉價伺服器，1臺不夠就2臺，2臺不夠就10臺，10臺不夠那就百臺千臺。

那麼業務邏輯就完全不能交給資料庫麼？顯然不能這麼絕對，資料庫有資料庫的優勢，而且現在資料庫的讀寫分離，分庫分表等技術，也大大減輕了單臺數據庫服務的壓力。對於一些邏輯簡單而不會給資料庫造成過大壓力的業務查詢完全可以交給資料庫完成。無非是一個權衡利弊綜合考慮的經驗問題。