問答專欄Q & A COLUMN
先表明立場，任何時候都不要在后臺代碼里拼接sql。(除了中小公司內部報表類需求外)
首先，提主遇到的大公司拼接sql，“都”明顯是偽命題。在互聯網公司的應用領域內，是嚴禁嵌套，拼接sql的。一個大流量超高并發的系統，數據庫鏈接池資源，是非常寶貴的。基本決定了系統的性能上限。不然為什么加分布式緩存，數據庫分庫分表呢？對于高頻低熵的系統，明顯高頻次低耗時的數據庫鏈接是最可靠的方式。
其次，對于各種大型的傳統IT服務業和政府，銀行類系統，由于系統本身相對于一線互聯網公司，并發非常低。所以線程對數據庫鏈接的持有時間可以稍微耗時長一些，以得到比較快的系統響應。其實這么做，也并非是明智之舉。明顯，互聯網類的技術拆分和技術架構，對于大公司的各種場景更為合適。傳統的IT那種所有難題扔sql，扔給存儲過程的方式已經過時多年。
最后，對于高并發的大型在線系統，有復雜查詢類的需求，絕不推薦在后臺sql中用復雜的查詢去實現。這個對于系統的成本消耗明顯太高。對于復雜的查詢，自然有其他的技術架構去實現。
可以多多關注一線互聯網公司的架構技術，也可以看下我之前的回答。
發現持續還有人關注本問題，看到大家來自各個不同業務領域，再聊一些吧。
本身這個問題是高并發類系統的常識性問題。不管是低頻高熵的傳統業務，還是高頻低熵的互聯網業務公司，技術架構往往是業務特性來決定的。
傳統IT公司，IT服務類公司確實仍然存在拼接這樣粗暴的實現方式。因為并發低，迭代快。當然如果能滿足低頻低熵的業務需求，也無可厚非。但單單從技術角度看，這么做可能并不是最優。事實上，傳統公司的新項目也很少有人會這么玩了。(節省幾臺服務器，也是錢啊)。
很多同學領域不同，對業務需要的技術理解自然會有區別。技術同學可以適當多看機會，多接觸不同業務領域的技術實現方案。多思考技術架構這樣設計背后的業務原因。
另外，如果有任何問題或質疑，歡迎去看我之前的回答，或留言與我討論。不喜勿噴。
評論0
加載中...
題主說的確實存在，但是要區分不同業務類型和領域的“大”公司，軟件行業里面，有bat這樣的互聯網公司，也有神州這樣的看起來大的公司，也有藍凌這樣的專做OA的大公司，還有思迅這樣在收銀軟件獨霸一方的。他們在各自領域，都是大公司。
如果是傳統管理軟件的公司，這種情況確實大量存在。這和歷史原因，業務現狀有關。他們的主要問題是每天面臨大量不同項目的不同功能需求要完成，當合理的使用拼接sql方式，能夠加快開發交付速度，也能靈活面對業務需求的變化。這類軟件的業務復雜度遠大于并發需求，所以這樣也能抗住性能壓力，也能完成各種復雜功能（業務復雜{{BANNED}}程度遠超一般長期接觸互聯網行業的工程師的想象）的快速開發。
而如果是一個互聯網公司，業務又是2C的，那么就不會拼接sql了。往往采用基礎表的數據整條讀寫訪問（數據庫淪為持久化工具之一），數據內存做緩存，數據邏輯關系由代碼而不是sql完成，以提高效能，降低延遲，提高并發（按每秒單節點10w次記）。所以，這種大公司是絕不可能大量有sql拼接的，有也是少數sql，也或許是緩存穿透后的操作。
還有一種情況，就是大公司里面某些團隊，接了開發任務，項目又是項目產品型的，項目負責人開始為了加快進度，搭建的基礎架構就偏簡單，加之業務還沒成熟，技術選擇上也會采用拼接sql來實現，這樣對開發人員要求低，開發速度快。
綜上所屬，就會出現，題主說的情況，那些說沒有的人，也沒錯，他們只是單一行業接觸的多，跨行業領域接觸的少而已。
評論0
加載中...
看了回答。任何問題都不只是單純的技術問題。討論任何問題都應該有一個業務場景，所以造成了大家的爭論。
高并發場景下確實不建議復雜sql，查詢緩慢造成數據庫服務器的巨大壓力。
如果你的系統數據量沒那么大，并發也沒多少。寫個復雜sql有有什么問題呢？
有些公司采取的措施是一刀切，復雜sql不能有，嚴禁sql嵌套循環等。一刀切帶來的問題是可能不是一個問題，而為了解決所謂的問題浪費時間。我想說的是復雜sql效率不一定低，循環極少數次又有什么問題呢？最終的目的不還是為了保證查詢效率嗎？他們之間沒有必然的關系。這種問題可以采用開發規范或者代碼審核來避免。開發規范可以警示開發人員:聯合查詢n張表的時候需考慮性能問題，并考慮是否拆分sql。
還是那句話，脫離了業務場景討論技術就是耍流氓。
評論0
加載中...
看了一下評論，有的偏題有的不準確，為什么拼接sql，一句話就是：為了效率。如果使用orm框架各種封裝，效率顯然沒有直接sql來的更直接。這也是mybatis比hibernate現在更流行的一個原因。
評論0
加載中...
1.數據庫更換時，部分數據庫拼接的語法有區別，而orm框架基本做了兼容可以很方便的切換數據庫。
2.互聯網系統流量內容查詢不能過于復雜，所以使用orm已經可以滿足大部分需求。但是內部業務復雜的系統時，orm因為為了滿足1，大量的共通拼接查詢寫法效率相對較低，很難做查詢優化。所以所有的orm框架在提供對象關系管理的同時，也都提供了sql語法的支持為了滿足特殊業務需求。java的mybatis比hibernate更有效率的原因就在這。python的django中的orm框架因為語言性能的原因，orm寫法和sql寫法對比效果更明顯。orm在簡單的curd上是很方便的，但是碰到復雜邏輯時，如果設計未考慮到復雜的鏈接，單純使用orm就是災難。
評論0
加載中...
曾帶過一個項目，其中一個數據接口處理，orm需要14個小時，動不動over heap. 10多年沒碰代碼的我，被迫上線現場改用純sql,放數據庫處理，處理時間2分鐘以內。
評論0
加載中...0
回答0
回答0
回答1
回答0
回答0
回答0
回答0
回答0
回答0
回答
