問答專欄Q & A COLUMN
軟件項目本身會有很多分類。在IT傳統項目/內部系統中，往往仍有很多項目采用復雜邏輯寫入sql或存儲過程的做法。當然并不代表這個做法是最佳的。
還是先拋出結論。
單單從技術角度講，是絕不應該將復雜邏輯寫入sql的。如果題主對原因不敢興趣，看到這里就可以了。下面我會簡單解釋下這么做的一些原因。
首先，先說說傳統IT服務類項目。類似，電信，政企，銀行，XXX管理系統，XXX運維系統。
這類項目往往是國企，事業單位，外包，公司內部，系統表現就是低頻高熵(即：系統的并發和用戶量不高，但是每次請求返回的數據量較大)。這類項目由于用戶少，系統壓力并不是特別大。采用復雜的sql語句去直接把壓力扔給數據庫，并不會有太大的問題。
另一方面，由于外包項目和內部系統，往往存在開發周期短，資金供給不太足，所以一般會采用這種較快的開發方式。復雜的數據處理，邏輯過濾，都會一股腦的扔給數據庫去處理。但是，單單從技術角度看，從系統性能和單機的用戶容量上看，這么做，顯然不是特別科學。完全可以用更少的機器，去支持更多的用戶。
其次，常見的互聯網技術架構。類似在線電商，O2O，生鮮等。
互聯網公司由于大多系統是高頻低熵(即系統的并發和用戶量巨大，但是每個用戶返回的數據只和自己訂單相關，數據量少)。而高并發的系統瓶頸，往往在網絡IO和磁盤IO上。數據庫的吞吐，很快會成為系統性能的瓶頸。因此，對于高并發大流量的系統，我們要盡可能的減少數據庫壓力，使單次查詢的時間盡可能短。緩存和分庫分表等一系列操作，都是為了盡可能的減少數據庫的讀寫壓力。
這里貼上一張常見的互聯網公司數據切片的操作。
最后，作為技術人員，我推薦采用互聯網技術架構的思路去解決項目中的數據庫問題。以最少的成本，性能最好的優化代碼，才能提高相應的技術能力。如果所有問題丟sql，性能不夠加機器，同樣能解決問題，但顯然不是一個技術人員應有的追求。
當然至于代碼的可讀性，可維護性等其他的，這些也算是原因之一，但并非是主要原因。
對互聯網公司技術架構設計有興趣，歡迎查看我之前的回答，里面有相關的公司架構設計發展的歷程。有問題隨時討論，謝謝。
評論0
加載中...
首先復雜的邏輯寫進sql，會大大減少業務邏輯和業務代碼的編寫，但1.可讀性不強，2.不易擴展，3.不好維護，建議視情況而定。另外sql編寫不宜關聯太多表影響性能容易出現慢查詢導致系統崩潰。
評論0
加載中...
復雜的邏輯怎么寫進sql中？
sql是對數據庫管理系統操作數據表的語言命令，復雜的邏輯是對不同sql語句的調用，難道能寫進去？
再者編程的一大特點就是高內聚，低耦合，單一原則，一個邏輯一段代碼執行一個功能，你非要耦合到一塊，后期怎么維護，怎么升級？
評論0
加載中...
是否應該將復雜的邏輯寫進sql中，取決于以下要素：
1、是不是要面對多個應用的調用？例如：A應用和B應用都需要調用的，直接寫到SQL中是可以的，可以避免多應用之間重復編碼，更新同步不及時等；如果只在一個應用或模塊中調用，不建議寫進SQL中，畢竟SQL語言的靈活性不如市面多數開發語言；
2、是不是需要考慮業務邏輯的安全性？在某些對業務邏輯有保密性要求的應用，直接寫到SQL中是可以的，有助于減少應用開發過程中的業務邏輯安全風險；
3、邏輯變化程度？對于經常需要變更的邏輯，寫到SQL中是不明智的。SQL編寫效率，測試效率都不如市面多數開發語言。
4、項目開發團隊的能力偏向？如果項目中，團隊主要成員傾向于將復雜的邏輯寫進sql中并且其他（她）成員沒有能力完成業務邏輯時，就應該將復雜的邏輯寫進sql中，加快項目推進與可靠性。
評論0
加載中...
用數據庫處理業務邏輯是非常好的做法，但是把業務邏輯寫進SQL文就不值得推薦了。
數據庫可以直接對應各種業務模型，代碼簡單明了，省去了很多內存操作和多余的流程控制邏輯。實際開發中應該最大限度地把這些優勢發揮出來。
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
