SQL數(shù)據(jù)庫(kù)，用forxmlpath字符串拼接，拼接內(nèi)容如何排序？SELECT b.列1，LEFT(List，LEN(List)-1) as Num FROM (SELECT 列1，(SELECT 列

SQL數(shù)據(jù)庫(kù)，用forxmlpath字符串拼接，拼接內(nèi)容如何排序？

SELECT b.列1，LEFT(List，LEN(List)-1) as Num FROM (SELECT 列1，(SELECT 列2 "，" FROM 表 WHERE 列1=a.列1 FOR XML PATH("")) AS ListFROM 表 a GROUP BY 列1) b

為什么一些大公司都喜歡用字符串拼接sql？

先表明立場(chǎng)，任何時(shí)候都不要在后臺(tái)代碼里拼接sql。(除了中小公司內(nèi)部報(bào)表類需求外)

首先，提主遇到的大公司拼接sql，“都”明顯是偽命題。在互聯(lián)網(wǎng)公司的應(yīng)用領(lǐng)域內(nèi)，是嚴(yán)禁嵌套，拼接sql的。一個(gè)大流量超高并發(fā)的系統(tǒng)，數(shù)據(jù)庫(kù)鏈接池資源，是非常寶貴的?；緵Q定了系統(tǒng)的性能上限。不然為什么加分布式緩存，數(shù)據(jù)庫(kù)分庫(kù)分表呢？對(duì)于高頻低熵的系統(tǒng)，明顯高頻次低耗時(shí)的數(shù)據(jù)庫(kù)鏈接是最可靠的方式。

其次，對(duì)于各種大型的傳統(tǒng)IT服務(wù)業(yè)和政府，銀行類系統(tǒng)，由于系統(tǒng)本身相對(duì)于一線互聯(lián)網(wǎng)公司，并發(fā)非常低。所以線程對(duì)數(shù)據(jù)庫(kù)鏈接的持有時(shí)間可以稍微耗時(shí)長(zhǎng)一些，以得到比較快的系統(tǒng)響應(yīng)。其實(shí)這么做，也并非是明智之舉。明顯，互聯(lián)網(wǎng)類的技術(shù)拆分和技術(shù)架構(gòu)，對(duì)于大公司的各種場(chǎng)景更為合適。傳統(tǒng)的IT那種所有難題扔sql，扔給存儲(chǔ)過程的方式已經(jīng)過時(shí)多年。

最后，對(duì)于高并發(fā)的大型在線系統(tǒng)，有復(fù)雜查詢類的需求，絕不推薦在后臺(tái)sql中用復(fù)雜的查詢?nèi)?shí)現(xiàn)。這個(gè)對(duì)于系統(tǒng)的成本消耗明顯太高。對(duì)于復(fù)雜的查詢，自然有其他的技術(shù)架構(gòu)去實(shí)現(xiàn)。

可以多多關(guān)注一線互聯(lián)網(wǎng)公司的架構(gòu)技術(shù)，也可以看下我之前的回答。

發(fā)現(xiàn)持續(xù)還有人關(guān)注本問題，看到大家來自各個(gè)不同業(yè)務(wù)領(lǐng)域，再聊一些吧。

本身這個(gè)問題是高并發(fā)類系統(tǒng)的常識(shí)性問題。不管是低頻高熵的傳統(tǒng)業(yè)務(wù)，還是高頻低熵的互聯(lián)網(wǎng)業(yè)務(wù)公司，技術(shù)架構(gòu)往往是業(yè)務(wù)特性來決定的。

傳統(tǒng)IT公司，IT服務(wù)類公司確實(shí)仍然存在拼接這樣粗暴的實(shí)現(xiàn)方式。因?yàn)椴l(fā)低，迭代快。當(dāng)然如果能滿足低頻低熵的業(yè)務(wù)需求，也無可厚非。但單單從技術(shù)角度看，這么做可能并不是最優(yōu)。事實(shí)上，傳統(tǒng)公司的新項(xiàng)目也很少有人會(huì)這么玩了。(節(jié)省幾臺(tái)服務(wù)器，也是錢啊)。

很多同學(xué)領(lǐng)域不同，對(duì)業(yè)務(wù)需要的技術(shù)理解自然會(huì)有區(qū)別。技術(shù)同學(xué)可以適當(dāng)多看機(jī)會(huì)，多接觸不同業(yè)務(wù)領(lǐng)域的技術(shù)實(shí)現(xiàn)方案。多思考技術(shù)架構(gòu)這樣設(shè)計(jì)背后的業(yè)務(wù)原因。

另外，如果有任何問題或質(zhì)疑，歡迎去看我之前的回答，或留言與我討論。不喜勿噴。