問答專欄Q & A COLUMN
目前大部分研發團隊都要求業務邏輯用代碼來實現，SQL操作往往都是基本操作。用SQL來表現業務邏輯，也就是通過存儲過程的方式來表現業務邏輯是比較傳統的開發方案。
在C/S時代很多邏輯的實現都是通過SQL來實現的，主要原因是業務規模和部署方式決定的。早期的C/S編程時代往往都是非分布式環境下的開發，而且大多數情況下并不需要考慮移植性問題，此時采用SQL來完成業務邏輯是比較方便的處理方式。
采用存儲過程來完成業務邏輯最大的好處是性能會比較好，但是這也取決于業務規模的大小，如果業務規模過大，那么性能會下降的比較厲害。而早期的數據存儲規模比較小，所以采用存儲過程的方式是比較方便的。
目前的Web開發已經到了大數據時代、云計算時代，業務類型和業務規模都有了較大的變化，尤其是大數據時代下NoSql數據庫的廣泛采用，使用SQL語句來完成業務邏輯的情景就更少了。而且，目前的程序大部分都是分布式方式，采用Sql存儲過程的方式來處理業務邏輯會非常麻煩，而且會導致整個項目的移植性和可讀性都嚴重下降。
目前在傳統企業的開發團隊中采用Sql來處理業務邏輯的情況比較常見，因為大部分傳統企業的數據庫還依然是關系型數據庫，而且不存在移植性要求，這種固定場景下的開發是完全可以使用Sql來處理業務邏輯的。未來使用Sql處理業務邏輯的情況也有一定的應用場景，所以學習存儲過程的編寫還是有一定必要的。
我的研究方向是大數據和人工智能，目前也在帶大數據方向的研究生，我會陸續在頭條上寫一些關于大數據方面的文章，感興趣的朋友可以關注我的頭條號，相信一定會有所收獲。
如果有大數據方面的問題，也可以咨詢我。
謝謝！
評論0
加載中...
個人建議，普通的業務邏輯盡量寫在后臺代碼中，盡量避免寫在SQL中，并且盡量避免使用存儲過程。
不可否認將業務邏輯寫在SQL或存儲過程中，也是有這種做法的優點，比如：可以減少網絡交互的成本，原本后臺程序需要多次訪問數據庫，現在可以用復雜的SQL或者存儲過程封裝好，然后程序調用一次即可。
但是復雜SQL和存儲過程也有很大的缺點：
不可移植性，每種數據庫的語法多多少少都會有一些差異；如果SQL中使用到數據的一些函數、方法，而這些又是該數據獨有的，那么很難做數據庫的遷移。
業務邏輯會存在SQL和程序中，這種業務邏輯多處存在，會讓后期的系統維護和調試都變得更加困難。
數據庫中所支持的函數及語法不一定可以滿足所有的需求，相比來說，編程語言中的功能更加的強大。
如果SQL、存儲過程中有復雜的計算，也會增加數據庫機器的壓力；并且很難做到分布式部署。
相比編程語言，業務邏輯寫在SQL、存儲過程中，很難做到業務邏輯的抽象，所以從代碼復用的角度來看，編程語言更勝一籌。
所以，普通業務邏輯盡量不要使用復雜SQL或存儲過程，而如果是報表統計或者ETL抽取等功能，可以根據實際的情況，采用復雜SQL或者存儲過程來處理。
評論0
加載中...
根據項目組的特點來。
如果團隊健康，寫在代碼中。
如果團隊不健康，大部分是剛參加工作的，那就寫在sql中，經驗者維護。
評論0
加載中...
早期CS架構開發，主要針對企業應用，S端就是數據庫端，那時幾乎所有的業務都是在存儲過程中完成，為什么？因為數據庫服務器足夠強勁，動輒上千萬的小型機，想想那時候Oracle的風光。
但隨著web的興起，BS開發架構逐漸成為主流，這里的S已經不局限于數據庫服務，特別是三層及多層架構的普及后，業務實現的重心已經遷移到web服務器中，為什么？因為數據庫服務已經不能承載面向全球百萬級甚至億級用戶請求的計算壓力。唯一的解決辦法就是分布式的集群方案，算力不夠，服務器來湊，不買性能強勁的昂貴的服務器，轉而購買巨大數量的性價比高的廉價服務器，1臺不夠就2臺，2臺不夠就10臺，10臺不夠那就百臺千臺。
那么業務邏輯就完全不能交給數據庫么？顯然不能這么絕對，數據庫有數據庫的優勢，而且現在數據庫的讀寫分離，分庫分表等技術，也大大減輕了單臺數據庫服務的壓力。對于一些邏輯簡單而不會給數據庫造成過大壓力的業務查詢完全可以交給數據庫完成。無非是一個權衡利弊綜合考慮的經驗問題。
評論0
加載中...
如果是小項目，業務層寫在存儲過程中也無妨，如果是大型項目，勸你還是封裝起來寫代碼里，假設大型項目的業務層寫在存儲過程中，拋開性能不說，后期維護起來豪不夸張的說就三個字:要你命
評論0
加載中...
關于這個問題應該分場景，不能一概而論。中小項目推薦使用存儲過程解決大部分業務，代碼量少，方便維護。大型項目涉及到分布式，緩存等等，考慮到數據庫的開銷就不建議太過依托數據庫處理了，因為大并發下數據庫處理復雜業務根本處理不過來。
評論0
加載中...
目前能想到的場景里 只有統計報表系統 部分報表聚合邏輯適合寫在sql中 開發效率較寫在中間層要高 大部分報表可以做到sql查詢所見即所得。但是 要求研發有很強的集合概念 熟悉庫表結構 sql語法 和 各種sql方言
其他場景 例如 各個業務線比入訂單流程 等 數據庫的作用還是回歸存儲 比較好 其他的邏輯控制等防在中間層比較好
評論0
加載中...
SQL做些基本操作就可以了，業務判斷還是要在代碼中實現，但在做報表的時候，按照在代碼中用增刪改查來操作，會存在大量的查詢和更新，這是極其耗時的，應該盡可能用一條SQL去完成，同時還要注意性能優化。
評論0
加載中...0
回答0
回答0
回答0
回答10
回答0
回答0
回答2
回答0
回答0
回答
