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