軟件項目本身會有很多分類。在IT傳統(tǒng)項目/內(nèi)部系統(tǒng)中，往往仍有很多項目采用復(fù)雜邏輯寫入sql或存儲過程的做法。當(dāng)然并不代表這個做法是最佳的。

還是先拋出結(jié)論。

單單從技術(shù)角度講，是絕不應(yīng)該將復(fù)雜邏輯寫入sql的。如果題主對原因不敢興趣，看到這里就可以了。下面我會簡單解釋下這么做的一些原因。

首先，先說說傳統(tǒng)IT服務(wù)類項目。類似，電信，政企，銀行，XXX管理系統(tǒng)，XXX運維系統(tǒng)。

這類項目往往是國企，事業(yè)單位，外包，公司內(nèi)部，系統(tǒng)表現(xiàn)就是低頻高熵(即：系統(tǒng)的并發(fā)和用戶量不高，但是每次請求返回的數(shù)據(jù)量較大)。這類項目由于用戶少，系統(tǒng)壓力并不是特別大。采用復(fù)雜的sql語句去直接把壓力扔給數(shù)據(jù)庫，并不會有太大的問題。

另一方面，由于外包項目和內(nèi)部系統(tǒng)，往往存在開發(fā)周期短，資金供給不太足，所以一般會采用這種較快的開發(fā)方式。復(fù)雜的數(shù)據(jù)處理，邏輯過濾，都會一股腦的扔給數(shù)據(jù)庫去處理。但是，單單從技術(shù)角度看，從系統(tǒng)性能和單機的用戶容量上看，這么做，顯然不是特別科學(xué)。完全可以用更少的機器，去支持更多的用戶。

其次，常見的互聯(lián)網(wǎng)技術(shù)架構(gòu)。類似在線電商，O2O，生鮮等。

互聯(lián)網(wǎng)公司由于大多系統(tǒng)是高頻低熵(即系統(tǒng)的并發(fā)和用戶量巨大，但是每個用戶返回的數(shù)據(jù)只和自己訂單相關(guān)，數(shù)據(jù)量少)。而高并發(fā)的系統(tǒng)瓶頸，往往在網(wǎng)絡(luò)IO和磁盤IO上。數(shù)據(jù)庫的吞吐，很快會成為系統(tǒng)性能的瓶頸。因此，對于高并發(fā)大流量的系統(tǒng)，我們要盡可能的減少數(shù)據(jù)庫壓力，使單次查詢的時間盡可能短。緩存和分庫分表等一系列操作，都是為了盡可能的減少數(shù)據(jù)庫的讀寫壓力。

這里貼上一張常見的互聯(lián)網(wǎng)公司數(shù)據(jù)切片的操作。

最后，作為技術(shù)人員，我推薦采用互聯(lián)網(wǎng)技術(shù)架構(gòu)的思路去解決項目中的數(shù)據(jù)庫問題。以最少的成本，性能最好的優(yōu)化代碼，才能提高相應(yīng)的技術(shù)能力。如果所有問題丟sql，性能不夠加機器，同樣能解決問題，但顯然不是一個技術(shù)人員應(yīng)有的追求。

當(dāng)然至于代碼的可讀性，可維護性等其他的，這些也算是原因之一，但并非是主要原因。

對互聯(lián)網(wǎng)公司技術(shù)架構(gòu)設(shè)計有興趣，歡迎查看我之前的回答，里面有相關(guān)的公司架構(gòu)設(shè)計發(fā)展的歷程。有問題隨時討論，謝謝。