T-SQL Cast กับการแปลง

325

อะไรคือคำแนะนำทั่วไปเมื่อคุณควรใช้CASTกับCONVERT? มีปัญหาเกี่ยวกับประสิทธิภาพใด ๆ ที่เกี่ยวข้องกับการเลือกหนึ่งกับอีกประเด็นหนึ่งหรือไม่? หนึ่งใกล้ ANSI-SQL หรือไม่

— BuddyJoe
แหล่งที่มา

339

CONVERTเป็นเฉพาะของ SQL Server CASTคือ ANSI

CONVERTมีความยืดหยุ่นมากขึ้นในการที่คุณสามารถจัดรูปแบบวันที่และอื่น ๆ นอกจากนั้นพวกเขาจะเหมือนกันมาก CASTหากคุณไม่สนใจเกี่ยวกับคุณสมบัติการขยายการใช้งาน

แก้ไข:

ตามที่บันทึกไว้โดย @beruic และ @CF ในความคิดเห็นด้านล่างมีความเป็นไปได้ที่จะสูญเสียความแม่นยำเมื่อมีการใช้การแปลงโดยนัย (นั่นคือที่ซึ่งคุณใช้ทั้ง CAST และ CONVERT) สำหรับข้อมูลเพิ่มเติมโปรดดูที่นักแสดงและแปลงและโดยเฉพาะกราฟิกนี้: แผนภูมิ SQL Server Data ประเภท Conversion ด้วยข้อมูลเพิ่มเติมนี้คำแนะนำดั้งเดิมยังคงเหมือนเดิม ใช้นักแสดงเมื่อเป็นไปได้

— Matthew Farwell
แหล่งที่มา

5

นอกจากนี้ฉันเชื่อว่ามีการแปลงตัวเลขที่ควรใช้ CAST เพื่อรักษาความแม่นยำ แต่ฉันมีปัญหาในการค้นหาแหล่งที่เชื่อถือได้สำหรับข้อมูลนี้

— beruic

2

@beruic คุณถูกต้องมีข้อมูลใน MSDN: msdn.microsoft.com/en-us/library/ms187928.aspx CAST จำเป็นต้องรักษาความแม่นยำเมื่อทำการแปลงระหว่างประเภท DECIMAL และ NUMERIC

— CF

@CF คุณเห็นข้อมูลนี้ที่ไหน ฉันได้ติดตามลิงก์ซึ่งเปิดหน้าทั่วไปของ CAST และ CONVERT และข้อมูลเฉพาะเกี่ยวกับความแม่นยำที่ฉันสามารถหาได้คือการแปลงค่าทศนิยมที่ใช้สัญลักษณ์ทางวิทยาศาสตร์ ฉันอาจจะผิดในความคิดเห็นเริ่มต้นของฉัน?

— beruic

6

@beruic มันเกี่ยวกับภาพนี้ที่ด้านล่างของบทความi.msdn.microsoft.com/dynimg/IC170617.gifตอนนี้ฉันคิดว่าบางทีความสูญเสียที่แม่นยำอาจเกิดขึ้นในการแปลงโดยนัยและไม่เกิดขึ้นเมื่อใช้ CAST หรือ CONVERT . ยังไม่ค่อยชัดเจน ...

— CF

2

@CF ฉันยอมรับว่ามันไม่ชัดเจนและควรมีเอกสารที่เฉพาะเจาะจงมากขึ้นเกี่ยวกับเรื่องนี้ดังนั้นหวังว่า Microsoft จะทำเช่นนี้ แต่เห็นดี :)

— beruic

29

การแปลงมีพารามิเตอร์สไตล์สำหรับการแปลงสตริงเป็นวันที่

http://msdn.microsoft.com/en-us/library/ms187928.aspx

— jason saldo
แหล่งที่มา

12

CAST เป็น SQL มาตรฐาน แต่ CONVERT ใช้สำหรับภาษา T-SQL เท่านั้น เรามีข้อได้เปรียบเล็กน้อยสำหรับการแปลงในกรณีของวันที่และเวลา

ด้วย CAST คุณจะระบุนิพจน์และประเภทเป้าหมาย ด้วย CONVERT มีอาร์กิวเมนต์ที่สามที่แสดงถึงสไตล์ของการแปลงซึ่งรองรับการแปลงบางอย่างเช่นระหว่างสตริงอักขระและค่าวันที่และเวลา ตัวอย่างเช่น CONVERT (DATE, '1/2/2012', 101) แปลงสตริงอักขระตัวอักษรเป็น DATE โดยใช้สไตล์ 101 ซึ่งเป็นตัวแทนของมาตรฐานสหรัฐอเมริกา

— Abdeloihab Bourassi
แหล่งที่มา

8

เพื่อขยายคำตอบที่_{คัดลอกโดย Shakti}ฉันสามารถวัดความแตกต่างระหว่างทั้งสองฟังก์ชั่นได้

ฉันถูกทดสอบประสิทธิภาพของรูปแบบของการแก้ปัญหาให้กับคำถามนี้และพบว่าส่วนเบี่ยงเบนมาตรฐานและสูงสุด runtimes CASTมีขนาดใหญ่เมื่อใช้

_{* เวลาเป็นมิลลิวินาทีปัดเศษเป็น 1 / 300th ของวินาทีตามค่าความแม่นยำของDateTimeประเภท}

— Elaskanator
แหล่งที่มา

6

บางสิ่งบางอย่างที่ไม่มีใครสังเกตเห็นได้ยังสามารถอ่านได้ มี ...

CONVERT(SomeType,
    SomeReallyLongExpression
    + ThatMayEvenSpan
    + MultipleLines
    )

... อาจเข้าใจง่ายกว่า ...

CAST(SomeReallyLongExpression
    + ThatMayEvenSpan
    + MultipleLines
    AS SomeType
    )

— Atario
แหล่งที่มา

2

แต่ฉันคิดว่านักแสดงมักอ่านได้มากกว่า CAST(Column1 AS int)มีเหตุผลมากกว่าที่จะอ่านมากกว่าCONVERT(int, Column1)สำหรับการแสดงออกที่ยาว

— S.Serpooshan

4

นักแสดงใช้มาตรฐาน ANSI ในกรณีของการพกพาสิ่งนี้จะทำงานบนแพลตฟอร์มอื่น ๆ แปลงเฉพาะเซิร์ฟเวอร์ sql แต่ฟังก์ชั่นที่แข็งแกร่งมาก คุณสามารถระบุสไตล์ที่แตกต่างสำหรับวันที่

— RakeshP
แหล่งที่มา