問答專欄Q & A COLUMN
軟件項目本身會有很多分類。在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運(yùn)維系統(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)性能和單機(jī)的用戶容量上看，這么做，顯然不是特別科學(xué)。完全可以用更少的機(jī)器，去支持更多的用戶。
其次，常見的互聯(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，性能不夠加機(jī)器，同樣能解決問題，但顯然不是一個技術(shù)人員應(yīng)有的追求。
當(dāng)然至于代碼的可讀性，可維護(hù)性等其他的，這些也算是原因之一，但并非是主要原因。
對互聯(lián)網(wǎng)公司技術(shù)架構(gòu)設(shè)計有興趣，歡迎查看我之前的回答，里面有相關(guān)的公司架構(gòu)設(shè)計發(fā)展的歷程。有問題隨時討論，謝謝。
評論0
加載中...
不應(yīng)該，業(yè)務(wù)在service里寫就好了，甚至join操作都不應(yīng)該，我們的分布式數(shù)據(jù)庫都不支持join,因為沒必要
評論0
加載中...
首先復(fù)雜的邏輯寫進(jìn)sql，會大大減少業(yè)務(wù)邏輯和業(yè)務(wù)代碼的編寫，但1.可讀性不強(qiáng)，2.不易擴(kuò)展，3.不好維護(hù)，建議視情況而定。另外sql編寫不宜關(guān)聯(lián)太多表影響性能容易出現(xiàn)慢查詢導(dǎo)致系統(tǒng)崩潰。
評論0
加載中...
建議復(fù)雜的sql寫入程序里面，程序可以集群部署，分散應(yīng)用程序壓力，避免大流量壓力直接打到數(shù)據(jù)庫服務(wù)器，直接導(dǎo)致數(shù)據(jù)庫宕機(jī)。
評論0
加載中...
復(fù)雜的邏輯怎么寫進(jìn)sql中？
sql是對數(shù)據(jù)庫管理系統(tǒng)操作數(shù)據(jù)表的語言命令，復(fù)雜的邏輯是對不同sql語句的調(diào)用，難道能寫進(jìn)去？
再者編程的一大特點(diǎn)就是高內(nèi)聚，低耦合，單一原則，一個邏輯一段代碼執(zhí)行一個功能，你非要耦合到一塊，后期怎么維護(hù)，怎么升級？
評論0
加載中...
是否應(yīng)該將復(fù)雜的邏輯寫進(jìn)sql中，取決于以下要素：
1、是不是要面對多個應(yīng)用的調(diào)用？例如：A應(yīng)用和B應(yīng)用都需要調(diào)用的，直接寫到SQL中是可以的，可以避免多應(yīng)用之間重復(fù)編碼，更新同步不及時等；如果只在一個應(yīng)用或模塊中調(diào)用，不建議寫進(jìn)SQL中，畢竟SQL語言的靈活性不如市面多數(shù)開發(fā)語言；
2、是不是需要考慮業(yè)務(wù)邏輯的安全性？在某些對業(yè)務(wù)邏輯有保密性要求的應(yīng)用，直接寫到SQL中是可以的，有助于減少應(yīng)用開發(fā)過程中的業(yè)務(wù)邏輯安全風(fēng)險；
3、邏輯變化程度？對于經(jīng)常需要變更的邏輯，寫到SQL中是不明智的。SQL編寫效率，測試效率都不如市面多數(shù)開發(fā)語言。
4、項目開發(fā)團(tuán)隊的能力偏向？如果項目中，團(tuán)隊主要成員傾向于將復(fù)雜的邏輯寫進(jìn)sql中并且其他（她）成員沒有能力完成業(yè)務(wù)邏輯時，就應(yīng)該將復(fù)雜的邏輯寫進(jìn)sql中，加快項目推進(jìn)與可靠性。
評論0
加載中...
用數(shù)據(jù)庫處理業(yè)務(wù)邏輯是非常好的做法，但是把業(yè)務(wù)邏輯寫進(jìn)SQL文就不值得推薦了。
數(shù)據(jù)庫可以直接對應(yīng)各種業(yè)務(wù)模型，代碼簡單明了，省去了很多內(nèi)存操作和多余的流程控制邏輯。實(shí)際開發(fā)中應(yīng)該最大限度地把這些優(yōu)勢發(fā)揮出來。
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
