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