網(wǎng)友解答: 目前大部分研發(fā)團(tuán)隊(duì)都要求業(yè)務(wù)邏輯用代碼來(lái)實(shí)現(xiàn)，SQL操作往往都是基本操作。用SQL來(lái)表現(xiàn)業(yè)務(wù)邏輯，也就是通過(guò)存儲(chǔ)過(guò)程的方式來(lái)表現(xiàn)業(yè)務(wù)邏輯是比較傳統(tǒng)的開(kāi)發(fā)方案。在C/S時(shí)代很多

目前大部分研發(fā)團(tuán)隊(duì)都要求業(yè)務(wù)邏輯用代碼來(lái)實(shí)現(xiàn)，SQL操作往往都是基本操作。用SQL來(lái)表現(xiàn)業(yè)務(wù)邏輯，也就是通過(guò)存儲(chǔ)過(guò)程的方式來(lái)表現(xiàn)業(yè)務(wù)邏輯是比較傳統(tǒng)的開(kāi)發(fā)方案。

在C/S時(shí)代很多邏輯的實(shí)現(xiàn)都是通過(guò)SQL來(lái)實(shí)現(xiàn)的，主要原因是業(yè)務(wù)規(guī)模和部署方式?jīng)Q定的。早期的C/S編程時(shí)代往往都是非分布式環(huán)境下的開(kāi)發(fā)，而且大多數(shù)情況下并不需要考慮移植性問(wèn)題，此時(shí)采用SQL來(lái)完成業(yè)務(wù)邏輯是比較方便的處理方式。

采用存儲(chǔ)過(guò)程來(lái)完成業(yè)務(wù)邏輯最大的好處是性能會(huì)比較好，但是這也取決于業(yè)務(wù)規(guī)模的大小，如果業(yè)務(wù)規(guī)模過(guò)大，那么性能會(huì)下降的比較厲害。而早期的數(shù)據(jù)存儲(chǔ)規(guī)模比較小，所以采用存儲(chǔ)過(guò)程的方式是比較方便的。

目前的Web開(kāi)發(fā)已經(jīng)到了大數(shù)據(jù)時(shí)代、云計(jì)算時(shí)代，業(yè)務(wù)類(lèi)型和業(yè)務(wù)規(guī)模都有了較大的變化，尤其是大數(shù)據(jù)時(shí)代下NoSql數(shù)據(jù)庫(kù)的廣泛采用，使用SQL語(yǔ)句來(lái)完成業(yè)務(wù)邏輯的情景就更少了。而且，目前的程序大部分都是分布式方式，采用Sql存儲(chǔ)過(guò)程的方式來(lái)處理業(yè)務(wù)邏輯會(huì)非常麻煩，而且會(huì)導(dǎo)致整個(gè)項(xiàng)目的移植性和可讀性都嚴(yán)重下降。

目前在傳統(tǒng)企業(yè)的開(kāi)發(fā)團(tuán)隊(duì)中采用Sql來(lái)處理業(yè)務(wù)邏輯的情況比較常見(jiàn)，因?yàn)榇蟛糠謧鹘y(tǒng)企業(yè)的數(shù)據(jù)庫(kù)還依然是關(guān)系型數(shù)據(jù)庫(kù)，而且不存在移植性要求，這種固定場(chǎng)景下的開(kāi)發(fā)是完全可以使用Sql來(lái)處理業(yè)務(wù)邏輯的。未來(lái)使用Sql處理業(yè)務(wù)邏輯的情況也有一定的應(yīng)用場(chǎng)景，所以學(xué)習(xí)存儲(chǔ)過(guò)程的編寫(xiě)還是有一定必要的。

我的研究方向是大數(shù)據(jù)和人工智能，目前也在帶大數(shù)據(jù)方向的研究生，我會(huì)陸續(xù)在酷米上寫(xiě)一些關(guān)于大數(shù)據(jù)方面的文章，感興趣的朋友可以關(guān)注我的酷米號(hào)，相信一定會(huì)有所收獲。

如果有大數(shù)據(jù)方面的問(wèn)題，也可以咨詢(xún)我。

謝謝！

寫(xiě)在SQL里面

優(yōu)勢(shì)：

* 性能較高

* 復(fù)雜查詢(xún)實(shí)現(xiàn)起來(lái)更直接簡(jiǎn)單。

劣勢(shì)：

* 數(shù)據(jù)字段變化，重構(gòu)麻煩。

* 腳本邏輯太多的時(shí)候，維護(hù)很麻煩。

* 復(fù)用設(shè)計(jì)更麻煩。

相對(duì)的如果通過(guò)ORM操作

優(yōu)勢(shì)：

* ORM一般適配了多種關(guān)系數(shù)據(jù)庫(kù)，便于切換不同庫(kù)（這個(gè)在開(kāi)發(fā)階段有可能用）

* 配合緩存使用，設(shè)計(jì)合理的話(huà)速度不會(huì)差異太大。

* 更自由地設(shè)計(jì)服務(wù)架構(gòu)，比如分布式鎖的使用。

劣勢(shì)：

* 出于性能考慮，需要確認(rèn)最終轉(zhuǎn)換的SQL是否合理（這個(gè)說(shuō)實(shí)話(huà)也不算劣勢(shì)）。

* 復(fù)雜查詢(xún)表達(dá)能力不如SQL直觀(guān)。

一般我會(huì)折衷，復(fù)雜的統(tǒng)計(jì)查詢(xún)之類(lèi)的用存儲(chǔ)過(guò)程或者視圖，其它的ORM。有些場(chǎng)合還會(huì)搭配Mongodb之類(lèi)的Nosql。