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

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

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

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

目前的Web開發(fā)已經(jīng)到了大數(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ù)方面的問題，也可以咨詢我。

謝謝！

寫在SQL里面

優(yōu)勢：

* 性能較高

* 復雜查詢實現(xiàn)起來更直接簡單。

劣勢：

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

* 腳本邏輯太多的時候，維護很麻煩。

* 復用設計更麻煩。

相對的如果通過ORM操作

優(yōu)勢：

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

* 配合緩存使用，設計合理的話速度不會差異太大。

* 更自由地設計服務架構，比如分布式鎖的使用。

劣勢：

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

* 復雜查詢表達能力不如SQL直觀。

一般我會折衷，復雜的統(tǒng)計查詢之類的用存儲過程或者視圖，其它的ORM。有些場合還會搭配Mongodb之類的Nosql。