主頁 > 知識庫 > SQL Server 中的數(shù)據(jù)類型隱式轉換問題

SQL Server 中的數(shù)據(jù)類型隱式轉換問題

熱門標簽:百度競價排名 呼叫中心市場需求 網(wǎng)站排名優(yōu)化 AI電銷 鐵路電話系統(tǒng) Linux服務器 地方門戶網(wǎng)站 服務外包

寫這篇文章的時候,還真不知道如何取名,也不知道這個該如何將其歸類。這個是同事遇到的一個案例,案例比較復雜,這里抽絲剝繭,僅僅構造一個簡單的案例來展現(xiàn)一下這個問題。我們先構造測試數(shù)據(jù),如下所示:

 CREATE TABLE TEST
( 
 ID INT, 
 GOOD_TYPE VARCHAR(12),
 GOOD_WEIGHT NUMERIC(18,2)
)
INSERT INTO dbo.TEST
VALUES( 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 NetWeight
FROM dbo.TEST
GROUP BY GOOD_TYPE;

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


當兩個不同數(shù)據(jù)類型的表達式用運算符組合后,優(yōu)先級較低的數(shù)據(jù)類型首先轉換為優(yōu)先級較高的數(shù)據(jù)類型。 如果此轉換不是所支持的隱式轉換,則返回錯誤。 對于組合具有相同數(shù)據(jù)類型的操作數(shù)表達式的運算符時,運算的結果便為該數(shù)據(jù)類型

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

參考資料:

https://docs.microsoft.com/zh-cn/sql/t-sql/data-types/data-type-precedence-transact-sql?view=sql-server-2017

https://docs.microsoft.com/zh-cn/sql/t-sql/data-types/data-type-conversion-database-engine?view=sql-server-2017

總結

以上所述是小編給大家介紹的SQL Server 中的數(shù)據(jù)類型隱式轉換問題,希望對大家有所幫助,如果大家有任何疑問請給我留言,小編會及時回復大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持!
如果你覺得本文對你有幫助,歡迎轉載,煩請注明出處,謝謝!

您可能感興趣的文章:
  • MySQL的隱式類型轉換整理總結
  • MySQL隱式類型的轉換陷阱和規(guī)則
  • 隱式轉換引起的sql慢查詢實戰(zhàn)記錄

標簽:蘭州 湖南 銅川 黃山 崇左 衡水 仙桃 湘潭

巨人網(wǎng)絡通訊聲明:本文標題《SQL Server 中的數(shù)據(jù)類型隱式轉換問題》,本文關鍵詞  ;如發(fā)現(xiàn)本文內容存在版權問題,煩請?zhí)峁┫嚓P信息告之我們,我們將及時溝通與處理。本站內容系統(tǒng)采集于網(wǎng)絡,涉及言論、版權與本站無關。
  • 相關文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266