本篇文章為大家展示了SQL Server 中數(shù)據(jù)類型怎么實(shí)現(xiàn)隱式轉(zhuǎn)換，內(nèi)容簡明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

我們一直強(qiáng)調(diào)網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站制作對(duì)于企業(yè)的重要性,如果您也覺得重要,那么就需要我們慎重對(duì)待,選擇一個(gè)安全靠譜的網(wǎng)站建設(shè)公司,企業(yè)網(wǎng)站我們建議是要么不做，要么就做好,讓網(wǎng)站能真正成為企業(yè)發(fā)展過程中的有力推手。專業(yè)網(wǎng)站制作公司不一定是大公司,創(chuàng)新互聯(lián)公司作為專業(yè)的網(wǎng)絡(luò)公司選擇我們就是放心。

如下所示：

 CREATE TABLE TEST(  ID INT,  GOOD_TYPE VARCHAR(12), GOOD_WEIGHT NUMERIC(18,2))INSERT INTO dbo.TESTVALUES( 1, 'T1',1.27) SELECT GOOD_TYPE,  CASE WHEN ( GOOD_TYPE = 'T1' ) THEN 99.1 + SUM(GOOD_WEIGHT)    ELSE CEILING(SUM(GOOD_WEIGHT))  END AS GrossWeight ,  SUM(GOOD_WEIGHT) AS NetWeightFROM dbo.TESTGROUP BY GOOD_TYPE;

如上所示，為什么99.1 + SUM(GOOD_WEIGHT)變成100了呢？ 原始SQL非常復(fù)雜，我們分析、排除掉各個(gè)因素后，始終不得要領(lǐng)，各種折騰中發(fā)現(xiàn)，如果這樣轉(zhuǎn)換一下（請(qǐng)見下面截圖），居然就OK了，后面分析了一下，應(yīng)該是CASE WHEN里面的不同數(shù)據(jù)類型導(dǎo)致隱式轉(zhuǎn)換，說實(shí)話之前還真沒有留意CASE WHEN中存在數(shù)據(jù)類型的隱性轉(zhuǎn)換，但是為什么就一定從NUMERIC轉(zhuǎn)換為INT了呢？ 而不是INT隱性轉(zhuǎn)換為NUMERIC呢， 說實(shí)話沒有看到相關(guān)文檔的官方，如果按照官方文檔：

當(dāng)兩個(gè)不同數(shù)據(jù)類型的表達(dá)式用運(yùn)算符組合后，優(yōu)先級(jí)較低的數(shù)據(jù)類型首先轉(zhuǎn)換為優(yōu)先級(jí)較高的數(shù)據(jù)類型。 如果此轉(zhuǎn)換不是所支持的隱式轉(zhuǎn)換，則返回錯(cuò)誤。 對(duì)于組合具有相同數(shù)據(jù)類型的操作數(shù)表達(dá)式的運(yùn)算符時(shí)，運(yùn)算的結(jié)果便為該數(shù)據(jù)類型

而我們知道，Decimal 和 NUMERIC 是同義詞，可互換使用，而官方文檔“數(shù)據(jù)類型優(yōu)先級(jí) (Transact-SQL)”中，Decimal的優(yōu)先級(jí)明顯高于INT，如果真要按照原理來解釋，應(yīng)該是INT轉(zhuǎn)換NUMERIC才對(duì)（兩種數(shù)據(jù)類型支持隱式轉(zhuǎn)換），所以越想越糊涂，只知道有這么一回事，但是真正的Root Cause尚不清楚，而且在精確度要求較高的報(bào)表中，這種現(xiàn)象就會(huì)類似Bug一樣的突然出現(xiàn)。需要謹(jǐn)慎留心！

上述內(nèi)容就是SQL Server 中數(shù)據(jù)類型怎么實(shí)現(xiàn)隱式轉(zhuǎn)換，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。