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