不應該，業務在service裡寫就好了，甚至join操作都不應該，我們的分散式資料庫都不支援join,因為沒必要

複雜的邏輯怎麼寫進sql中？

sql是對資料庫管理系統操作資料表的語言命令，複雜的邏輯是對不同sql語句的呼叫，難道能寫進去？

再者程式設計的一大特點就是高內聚，低耦合，單一原則，一個邏輯一段程式碼執行一個功能，你非要耦合到一塊，後期怎麼維護，怎麼升級？

首先複雜的邏輯寫進sql，會大大減少業務邏輯和業務程式碼的編寫，但1.可讀性不強，2.不易擴充套件，3.不好維護，建議視情況而定。另外sql編寫不宜關聯太多表影響效能容易出現慢查詢導致系統崩潰。

效能盡在掌控中，叢集，共享儲存，表分割槽，索引，in memory table, 安全，成熟，穩定，讓我更有自信。

能適應業務的快速變化，不需要打包編譯，大部分時候改下檢視或者儲存過程就ok. 往往用後臺程式碼寫的複雜邏輯只需要一條SQL就搞定（前提是保證效能），這樣能減少網路開銷，只傳輸需要的資料，減少網路呼叫次數，同時也減少了應用伺服器的壓力。

後臺程式太自由，標準不統一，維護成本更昂貴。 如果是一個Java專家或者架構師可能會這樣說，將邏輯儘量寫在後臺程式碼中，

理由如下： 後臺服務的擴充套件比資料庫擴充套件容易，理論上能無限水平擴充套件。 對資料庫的效能依賴小，可移植性好，阿里曾經在去IEO的浪場中由O移植到Mysql。 對於大部分的應用效能瓶頸都在資料庫的方面，表設計以及SQL應該儘量簡單,這樣各種ORM框架能發揮最大的用處。 關係資料庫有效能擴充套件瓶頸，對於大型網際網路應應該該鼓勵去關係化。

軟體專案本身會有很多分類。在IT傳統專案/內部系統中，往往仍有很多專案採用複雜邏輯寫入sql或儲存過程的做法。當然並不代表這個做法是最佳的。

還是先丟擲結論。

單單從技術角度講，是絕不應該將複雜邏輯寫入sql的。如果題主對原因不敢興趣，看到這裡就可以了。下面我會簡單解釋下這麼做的一些原因。

首先，先說說傳統IT服務類專案。類似，電信，政企，銀行，XXX管理系統，XXX運維繫統。

這類專案往往是國企，事業單位，外包，公司內部，系統表現就是低頻高熵(即：系統的併發和使用者量不高，但是每次請求返回的資料量較大)。這類專案由於使用者少，系統壓力並不是特別大。採用複雜的sql語句去直接把壓力扔給資料庫，並不會有太大的問題。

另一方面，由於外包專案和內部系統，往往存在開發週期短，資金供給不太足，所以一般會採用這種較快的開發方式。複雜的資料處理，邏輯過濾，都會一股腦的扔給資料庫去處理。但是，單單從技術角度看，從系統性能和單機的使用者容量上看，這麼做，顯然不是特別科學。完全可以用更少的機器，去支援更多的使用者。

其次，常見的網際網路技術架構。類似線上電商，O2O，生鮮等。

網際網路公司由於大多系統是高頻低熵(即系統的併發和使用者量巨大，但是每個使用者返回的資料只和自己訂單相關，資料量少)。而高併發的系統瓶頸，往往在網路IO和磁碟IO上。資料庫的吞吐，很快會成為系統性能的瓶頸。因此，對於高併發大流量的系統，我們要儘可能的減少資料庫壓力，使單次查詢的時間儘可能短。快取和分庫分表等一系列操作，都是為了儘可能的減少資料庫的讀寫壓力。

這裡貼上一張常見的網際網路公司資料切片的操作。

最後，作為技術人員，我推薦採用網際網路技術架構的思路去解決專案中的資料庫問題。以最少的成本，效能最好的最佳化程式碼，才能提高相應的技術能力。如果所有問題丟sql，效能不夠加機器，同樣能解決問題，但顯然不是一個技術人員應有的追求。

當然至於程式碼的可讀性，可維護性等其他的，這些也算是原因之一，但並非是主要原因。

用資料庫處理業務邏輯是非常好的做法，但是把業務邏輯寫進SQL文就不值得推薦了。

消耗很多精力去拼湊SQL文，會使得程式可讀性變差，而且每次都要拼一大段SQL文，再提交給資料庫去編譯執行，這是效率很低的做法。有些程式為了避免出現這種情況就把大量資料讀進來，在本地進行篩選。這種做法又耗費了大量的網路資源和記憶體資源，也是不可取的。比較好的做法是，用資料庫的檢視預先實裝SQL文，這樣既可以在資料庫上處理業務邏輯，還可以用多少取多少，效率很高。不少高階資料庫還提供了儲存過程，這樣就可以方便地把追加和更新資料的操作也整合到資料庫裡。

資料庫可以直接對應各種業務模型，程式碼簡單明瞭，省去了很多記憶體操作和多餘的流程控制邏輯。實際開發中應該最大限度地把這些優勢發揮出來。