4 आउट-ऑफ़-द-बॉक्स SQL ​​डेटा रूपांतरण के तरीके और उपयोग के मामले

सबसे पहले, आप उनके बिना नहीं कर सकते, है ना?

SQL डेटा रूपांतरण या, विशेष रूप से, डेटा प्रकार रूपांतरण डेटाबेस डेवलपर या DBA के नियमित प्रोग्रामिंग कार्य का एक अनिवार्य हिस्सा हैं।

अब, क्या होगा यदि आपके बॉस ने आपके SQL सर्वर डेटाबेस से आने वाली टेक्स्ट प्रारूप में एक फ़ाइल प्रदान करने के लिए किसी अन्य कंपनी के साथ अनुबंध पर हस्ताक्षर किए हैं?

यह एक रोमांचक चुनौती की तरह लगता है!

लेकिन आपको पता चला कि आपको एक स्ट्रिंग की तारीख, एक संख्या से एक स्ट्रिंग, और अन्य SQL डेटा रूपांतरणों के एक समूह से निपटना होगा। क्या आप अभी भी चुनौती के लिए तैयार हैं?

डेटा रूपांतरण ट्रिक्स के आपके शस्त्रागार के बिना नहीं!

आउट-ऑफ़-द-बॉक्स क्या उपलब्ध है?

जब मैंने पहली बार टी-एसक्यूएल प्रोग्रामिंग शुरू की, तो मैंने जो पहली चीज देखी, वह रूपांतरण के उद्देश्य के अनुकूल थी CONVERT () समारोह।

इसके अलावा, "कन्वर्ट" शब्द है, है ना?

हालांकि यह सच हो सकता है, यह इस काम को करने के 4 तरीकों में से सिर्फ एक है। और मैं इसे अपने लगभग सभी SQL डेटा रूपांतरण के लिए उपयोग कर रहा था। मुझे खुशी है कि मैं इससे काफी आगे निकल चुका हूं। क्योंकि मैंने सीखा है कि आपके कोड में 4 विधियों का अपना स्थान है।

इससे पहले कि हम पोस्ट के विषय पर पहुँचें, मैं SQL डेटा रूपांतरण करने के लिए 4 आउट-ऑफ-द-बॉक्स विधियाँ प्रस्तुत करता हूँ:

• कास्ट करें ()
• बदलें ()
• पार्स ()
• TRY_CAST (), TRY_CONVERT (), TRY_PARSE ()

नीचे दिया गया प्रत्येक अनुभाग:

• स्पष्ट करें कि यह क्या है
• आपको बताएं कि इसका उपयोग कब करना है (मामलों का उपयोग करें)
• अपनी सीमाएं प्रस्तुत करें
• उदाहरण दें और समझाएं

इस लेख में प्रस्तुत सब कुछ यथासंभव सरल, सरल अंग्रेजी में है। जब तक आप पूरी पोस्ट को पढ़ना समाप्त कर लेंगे, तब तक आपको पता चल जाएगा कि किसी स्थिति के लिए कौन सी विधि उपयुक्त है।

तो, बिना किसी और हलचल के, आइए इसमें गोता लगाएँ।

1. CAST का उपयोग कर SQL डेटा रूपांतरण ()

जबकि आप देखेंगे कि सभी विधियां डेटा प्रकारों को परिवर्तित कर सकती हैं, रूपांतरण में आपकी पहली पसंद निश्चित रूप से CAST होनी चाहिए ()।

यहां इसके कारण बताए गए हैं:

• यह सभी का सबसे तेज़ चलने वाला रूपांतरण फ़ंक्शन है। हम इसे इस पोस्ट में बाद में साबित करने का प्रयास करेंगे।
• यह SQL-92 भाषा विनिर्देश मानकों में शामिल है। इसलिए जब आपको अपने कोड को अन्य SQL उत्पादों, जैसे MySQL में पोर्ट करने की आवश्यकता होती है, तो फ़ंक्शन भी उपलब्ध होता है।

यहां कास्ट . के लिए एक बहुत ही सरल सिंटैक्स दिया गया है ():

CAST( <expression> AS <data_type>[(length)] )

सबसे पहले, आइए सिंटैक्स की जांच करें:

• <अभिव्यक्ति> कोई भी मान्य व्यंजक है जिसके परिणामस्वरूप ऐसा मान प्राप्त होता है जिसे लक्ष्य डेटा प्रकार में परिवर्तित किया जा सकता है।
• <data_type> लक्ष्य डेटा प्रकार है।
• लंबाई वैकल्पिक है और यह डेटा के आकार से संबंधित है।

इसका उपयोग कब करें

यदि आपको केवल एक मान को किसी अन्य डेटा प्रकार में बदलने की आवश्यकता है, तो CAST () वही है जो आपको चाहिए।

सीमा

नकारात्मक पक्ष पर, कास्ट करें () आपको स्वरूपित दिनांक और समय मान जैसा स्वरूपित आउटपुट आउट-ऑफ़-द-बॉक्स नहीं दे सकता।

उदाहरण

<मजबूत>ए. स्ट्रिंग को दिनांक में बदलें:

SELECT CAST('09/11/2004 4:30PM' as datetime2)

और उपरोक्त कथन को चलाने का परिणाम होगा:

<मजबूत>बी. किसी संख्या को स्ट्रिंग में बदलें:

SELECT CAST(10.003458802 as varchar(max))

और उपरोक्त रूपांतरण का परिणाम है:

अब, यदि आपको परिवर्तित डेटा को स्वरूपित करने जैसी किसी अन्य चीज़ की आवश्यकता है, तो अगली विधि आपकी सहायता कर सकती है।

2. CONVERT ()

डेटा रूपांतरण का अगला विकल्प कन्वर्ट . का उपयोग करना है ()। जैसा कि मैंने पहले कहा, यह वही है जिसका मैंने पहले के दिनों में सबसे अधिक उपयोग किया था।

यहाँ सिंटैक्स है:

CONVERT( <data_type>[(length)], <expression> [, <style>])

ऊपर दिए गए सिंटैक्स से, ध्यान दें कि <शैली> पैरामीटर वैकल्पिक है। और जब तक आप इसे प्रदान नहीं करते, फ़ंक्शन CAST . के समान होगा ()।

यहीं से मेरी उलझन शुरू हुई जब मैं SQL में नया था।

इसका उपयोग कब करें

यदि आप डेटा को तत्काल प्रारूप में रूपांतरित करते हैं, तो रूपांतरित करें () आपका दोस्त है। इसका मतलब है कि आप <शैली . को अपनाते हैं> पैरामीटर ठीक से।

सीमाएं

• कास्ट करें () कन्वर्ट . से तेज है (), इसलिए यदि आपको केवल डेटा परिवर्तित करने की आवश्यकता है, तो CAST . का उपयोग करें ()। यदि आउटपुट स्वरूपित होना चाहिए, तो कन्वर्ट . का उपयोग करें ()।
• बदलें () SQL-92 मानक नहीं है, इसलिए यदि आपको इसे अन्य RDBMS में पोर्ट करने की आवश्यकता है, तो इसका उपयोग करने से बचें।

उदाहरण

<मजबूत>ए. किसी तिथि को स्ट्रिंग प्रारूप में बदलें yyyymmdd

निम्नलिखित उदाहरण में, मैं नमूना डेटाबेस का उपयोग करूंगा AdventureWorks और [प्रारंभ दिनांक . को रूपांतरित करें ] कॉलम से yyyymmdd :

USE AdventureWorks
GO
SELECT
[BillOfMaterialsID]
,CONVERT(varchar(10), [StartDate],112) as StartDate
FROM [Production].BillOfMaterials]
GO

ध्यान दें कि शैली 112 का उपयोग दिनांकों को yyyymmdd . को स्वरूपित करने के लिए किया जाता है ।

<मजबूत>बी. दशमलव बिंदु के बाईं ओर प्रत्येक 3 अंकों पर अल्पविराम के साथ एक संख्या को स्ट्रिंग में बदलें।

इसी तरह, निम्न उदाहरण AdventureWorks . का वर्णन करेगा नमूना डेटाबेस, और हम संख्या को अल्पविराम और 2 दशमलव स्थानों के साथ प्रारूपित करेंगे।

USE AdventureWorks
GO
SELECT
[TransactionID]
,[ProductID]
,CONVERT(varchar(10),[TransactionDate] ,112) as StartDate
,[Quantity]
,CONVERT(varchar(10),[ActualCost],1) as ActualCost
FROM [Production].TransactionHistory
GO

ध्यान दें कि प्रारूप 1 का उपयोग [वास्तविक लागत . के लिए किया जाता है ]. और कन्वर्ट . के लिए धन्यवाद (), हम इन स्तंभों को एक पल में प्रारूपित कर सकते हैं।

हालांकि, क्या होगा यदि आपको एक लंबी तिथि अभिव्यक्ति को परिवर्तित करने की आवश्यकता है? बदलेगा () उस मामले में काम? अगली विधि के बारे में जानने के लिए पढ़ें।

3. PARSE () का उपयोग करके SQL डेटा रूपांतरण

अगली विधि जिस पर हम विचार करने जा रहे हैं वह है PARSE ()।

सिंटैक्स देखें:

PARSE( <string value> AS <datatype> [USING <culture>])

इसका उपयोग कब करें

• किसी विशिष्ट संस्कृति का उपयोग करके तार को तारीखों या संख्याओं में बदलने के लिए।
• जब स्ट्रिंग को CAST . का उपयोग करके किसी तिथि या संख्या में परिवर्तित नहीं किया जा सकता है () या बदलें ()। अधिक जानकारी के लिए उदाहरण देखें।

सीमाएं

• केवल स्ट्रिंग से तिथियों और स्ट्रिंग से संख्याओं के लिए रूपांतरण संभव है
• सर्वर पर .Net Framework Common Language Runtime (CLR) की उपस्थिति पर निर्भर करता है।
• SQL-92 मानक विनिर्देशों में शामिल नहीं है, इसलिए अन्य RDBMS को पोर्ट करना एक समस्या है।
• जब स्ट्रिंग को पार्स करने की बात आती है तो प्रदर्शन ओवरहेड होता है।

उदाहरण

<मजबूत>ए. एक लंबी तिथि स्ट्रिंग को परिवर्तित करना

SELECT PARSE('Monday, June 8, 2020' as datetime USING 'en-US')

ऊपर दिया गया उदाहरण एक लंबी दिनांक स्ट्रिंग है जिसे डेटाटाइम . में परिवर्तित किया जाना है अमेरिकी अंग्रेजी संस्कृति का उपयोग कर मूल्य। और यहीं पर PARSE () अपना सर्वश्रेष्ठ प्रदर्शन करेगा।

ऐसा इसलिए है क्योंकि यदि आप CAST . का उपयोग करते हैं तो उपरोक्त कोड विफल हो जाएगा () या बदलें ()।

<मजबूत>बी. मुद्रा के प्रतीक के साथ धन मूल्य को परिवर्तित करना

SELECT PARSE('€1024,01' as money using 'de-DE')

अब, CAST . का उपयोग करके रूपांतरण करने का प्रयास करें () और बदलें ()

SELECT CONVERT(money,'€1024,01')
SELECT CAST('€1024,01' as money)

बयान में त्रुटियां नहीं होंगी, फिर भी, इस अप्रत्याशित परिणाम पर एक नज़र डालें:

परिणामस्वरूप, मान 1024.01 के बजाय 102401.00 में बदल दिया गया है।

अब तक, हमने पाया है कि पहली 3 विधियों में त्रुटियों की संभावना होती है जब तक कि आप उनकी जाँच नहीं करते। फिर भी, दोषपूर्ण परिणाम के लिए चौथा तरीका आपका समाधान हो सकता है।

4. TRY_CAST(), TRY_CONVERT(), या TRY_PARSE()

अंत में, SQL डेटा रूपांतरण के लिए अंतिम विधि पहले 3 के एक प्रकार का उपयोग कर रही है लेकिन TRY_ के उपसर्ग के साथ।

लेकिन फिर भी, क्या अंतर है?

उनके पास TRY_ उपसर्ग के बिना पिछले 3 के समान पैरामीटर हैं। लेकिन अंतर यह है कि वे NULL return लौटाते हैं यदि मान परिवर्तित नहीं किया जा सकता है। अब, यदि मान स्पष्ट रूप से 3 में से किसी के द्वारा परिवर्तित नहीं किया जा सकता है, तो एक त्रुटि होती है। बेहतर समझ के लिए नीचे दिए गए उदाहरण देखें।

इसका उपयोग कब करें

आप CASE . जैसे सशर्त कथनों के साथ 3 में से किसी का भी उपयोग कर सकते हैं कब या आईआईएफ त्रुटियों के परीक्षण के लिए।

सीमाएं

उनमें से 3 की सीमाएँ वही हैं जो TRY_ उपसर्ग के बिना हैं, उन मानों को छोड़कर जिन्हें परिवर्तित नहीं किया जा सकता है।

उदाहरण

<मजबूत>ए. IIF का उपयोग करके रूपांतरण सफल होगा या नहीं, इसका परीक्षण करने के लिए TRY_CAST() का उपयोग करें:

SELECT IIF(TRY_CAST('111b' AS real) IS NULL, 'Cast failed', 'Cast succeeded') AS Result

उपरोक्त कोड 'कास्ट विफल' लौटाएगा क्योंकि '111b' को असली में परिवर्तित नहीं किया जा सकता है . मूल्य से 'बी' हटा दें, और यह 'कास्ट सफल' वापस आ जाएगा।

<मजबूत>बी. किसी विशिष्ट प्रारूप वाली तिथियों पर TRY_CONVERT() का उपयोग करना

SET DATEFORMAT dmy;
SELECT TRY_CONVERT(datetime2, '12/31/2010') AS Result

यह NULL लौटाएगा क्योंकि प्रारूप dmy . का उपयोग करता है या दिन-महीने-वर्ष। और TRY_CONVERT . के लिए इनपुट व्यंजक () mdy . के प्रारूप में है या महीने-दिन-वर्ष। त्रुटि ट्रिगर हुई क्योंकि महीने का मान 31 है।

<मजबूत>सी. TRY_PARSE() का उपयोग करना जो रनटाइम त्रुटि उत्पन्न करेगा

SELECT
CASE WHEN TRY_PARSE('10/21/2133' AS smalldatetime USING 'en-US') IS NULL
    THEN 'True'
    ELSE 'False'
END AS Result

यह कोड एक रनटाइम त्रुटि उत्पन्न करेगा जैसा कि नीचे देखा गया है:

SQL डेटा रूपांतरण में 4 आउट-ऑफ-द-बॉक्स विधियों के लिए यही है। लेकिन अभी और भी बहुत कुछ आना बाकी है।

अंतर्निहित रूपांतरण का उपयोग करके SQL डेटा रूपांतरण के बारे में कैसे?

अब आइए निहित रूपांतरण पर विचार करें। यह मौन विधि है।

चुप क्यों?

क्योंकि हो सकता है कि आप इसे पहले से ही कर रहे हों, लेकिन आप इससे अनजान हैं। या कम से कम, आप जानते हैं कि यह हो रहा है, लेकिन आप इसे अनदेखा कर रहे हैं।

दूसरे शब्दों में, यह रूपांतरण का प्रकार है जो SQL बिना किसी फ़ंक्शन के स्वचालित रूप से करता है।

मैं आपको एक उदाहरण देता हूं:

DECLARE @char CHAR(25)
DECLARE @varchar VARCHAR(25)
DECLARE @nvarchar NVARCHAR(25)
DECLARE @nchar NCHAR(25)
 
SET @char = 'Live long and prosper'
SET @varchar = @char
SET @nvarchar = @varchar
SET @nchar = @nvarchar
 
SELECT @char AS [char], @varchar AS [varchar], @nvarchar AS [nvarchar], @nchar AS [nchar]

उपरोक्त कोड सफलतापूर्वक निष्पादित किया जाएगा। इसे स्वयं आज़माएं, और आपको नीचे दिए गए जैसा ही परिणाम मिलेगा:

आइए इसे तारीखों के साथ आज़माएँ:

DECLARE @datetime datetime
DECLARE @smalldatetime smalldatetime
DECLARE @datetime2 datetime2

SET @datetime = '12/31/2050 14:34'
SET @smalldatetime = @datetime
SET @datetime2 = @smalldatetime

SELECT @datetime as [datetime], @smalldatetime as [smalldatetime], @datetime2 as [datetime2]

जैसा कि अपेक्षित था, यह एक सफल परिणाम देगा:

आइए इस बार इसे संख्याओं के साथ आज़माएँ:

DECLARE @int int
DECLARE @real real
DECLARE @decimal decimal
DECLARE @float float

SET @int = 1701
SET @real = @int
SET @decimal = @real
SET @float = @decimal

SELECT @int as [int], @real as [real], @decimal as [decimal], @float as [float]

अभी भी सफल है, है ना?

अब तक, हमने सरल मानों का उपयोग किया है जो एक समान प्रकार के डेटा के लिए उपयुक्त होंगे। आइए अगले स्तर पर जाएं:संख्याओं से लेकर स्ट्रिंग तक।

DECLARE @number int
DECLARE @string varchar(5)

SET @number = 1701
SET @string = @number

SELECT @number as [number], @string as [string]

इसे सफलतापूर्वक रूपांतरित किया जाएगा जैसा कि आप नीचे दिए गए परिणाम से देख सकते हैं:

ऐसे कई और उदाहरण हैं जब SQL सर्वर "अनुमान" करने का प्रयास करेगा कि डेटा को कैसे परिवर्तित किया जाए। जैसा कि आप इस संदर्भ से देख सकते हैं, स्पष्ट रूपांतरण की आवश्यकता वाले उदाहरणों की तुलना में कई उदाहरण हैं।

चूंकि SQL सर्वर इसकी अनुमति देता है, क्या इसका मतलब यह है कि आप इसे अपने पूरे कोड में स्वतंत्र रूप से होने दे सकते हैं?

अंतर्निहित रूपांतरण में चेतावनी

एक बात के लिए, यह सुविधाजनक हो सकता है। लेकिन एक बार जब प्रत्येक डेटा प्रकार की सीमा समाप्त हो जाती है, तो आप महसूस करेंगे कि यदि अनियंत्रित छोड़ दिया जाए तो निहित रूपांतरण थोड़ा खतरनाक है।

नीचे एक उदाहरण पर विचार करें:

DECLARE @char char(25)
DECLARE @varchar varchar(25)
DECLARE @nvarchar nvarchar(25)
DECLARE @nchar nchar(25)

SET @nvarchar = N'I ❤ U!'
SET @nchar = @nvarchar 
SET @char = @nchar
SET @varchar = @nchar

SELECT @char as [char], @varchar as [varchar], @nvarchar as [nvarchar], @nchar as [nchar]

क्या आपने इमोजी वैल्यू देखी? यह एक यूनिकोड मान के रूप में गिना जाएगा।

जबकि ऊपर दिए गए सभी कथन सफलतापूर्वक चलेंगे, गैर-यूनिकोड प्रकार वाले चर जैसे varchar और चार अप्रत्याशित परिणाम होंगे। परिणाम नीचे देखें:

बहरहाल, यह एकमात्र समस्या नहीं है। जब मान सीमा से बाहर हो जाता है, तो त्रुटियाँ बाहर आ जाएँगी। तिथियों के साथ एक उदाहरण पर विचार करें:

DECLARE @datetime datetime
DECLARE @smalldatetime smalldatetime
DECLARE @datetime2 datetime2

SET @datetime = '12/31/2374 14:34'
SET @smalldatetime = @datetime
SET @datetime2 = @smalldatetime

SELECT @datetime as [datetime], @smalldatetime as [smalldatetime], @datetime2 as [datetime2]

डेटाटाइम . का असाइनमेंट स्मॉलडेटटाइम . के लिए मान वेरिएबल त्रुटि को ट्रिगर करेगा जैसा कि आप नीचे देख सकते हैं:

लेकिन एक और चेतावनी है, जिसे आपको अंतर्निहित रूपांतरण से निपटने के बारे में भी पता होना चाहिए:प्रदर्शन ओवरहेड। यह देखते हुए कि यह एक गर्म विषय है, यह एक अलग खंड के योग्य है।

विभिन्न SQL डेटा रूपांतरण विधियों के प्रदर्शन प्रभाव

मानो या न मानो, विभिन्न SQL डेटा रूपांतरण विधियों का वास्तविक परिस्थितियों में अलग-अलग प्रदर्शन होगा। और आपको कम से कम इसके बारे में पता होना चाहिए ताकि आप प्रदर्शन के नुकसान से बच सकें।

कैसे CAST(), CONVERT() और PARSE() प्रदर्शन करें

सबसे पहले, आइए देखें कि कैसे कास्ट करें (), बदलें (), और PARSE () जो तेज है उसकी तुलना करके प्राकृतिक परिस्थितियों में प्रदर्शन करें। हम यहां से लिए गए हमारे उदाहरण की अवधारणा को अनुकूलित और सिद्ध करते हैं। नीचे दिए गए कोड पर विचार करें:

USE AdventureWorks
GO

SET STATISTICS TIME ON
SELECT CAST([NationalIDNumber] as int) FROM [HumanResources].[Employee]
SELECT CONVERT(int,[NationalIDNumber]) FROM [HumanResources].[Employee]
SELECT PARSE([NationalIDNumber] as int) FROM [HumanResources].[Employee]
SET STATISTICS TIME OFF
GO

अब, उस कोड की जांच करें जो AdventureWorks . का उपयोग करता है माइक्रोसॉफ्ट से डेटाबेस:

• सांख्यिकी समय चालू करें प्रत्येक चयन . में CPU समय और बीता हुआ समय आउटपुट करेगा बयान
• फिर, प्रदर्शन उद्देश्यों के लिए परिवर्तित करने के लिए हम जिस कॉलम को चुनते हैं वह है [NationalIDNumber ], जिसका एक प्रकार है nvarchar(15) ।
• साथ ही, रूपांतरण एक स्ट्रिंग से एक पूर्णांक में होता है:nvarchar(15) से int . तक ।
• और अंत में, हम सांख्यिकी समय सेट करें . को पुनर्स्थापित करते हैं अपने पिछले मान तक

संदेशों . में आउटपुट पर ध्यान दें क्वेरी परिणाम का टैब:

यहाँ हम इस उदाहरण का उपयोग करके क्या लेकर आए हैं:

• यह साबित करता है कि कास्ट करें () सबसे तेज़ (1 ms.) और PARSE करता है () सबसे धीमा (318 एमएस) प्रदर्शन करता है।
• डेटा बदलने के लिए किस फ़ंक्शन का उपयोग करना है, यह तय करते समय हम इस प्राथमिकता का पालन करते हैं:(1 ) कास्ट करें () (2 ) बदलें () (3 ) PARSE ()।
• याद रखें कि प्रत्येक फ़ंक्शन कब प्रासंगिक होता है और किस फ़ंक्शन का उपयोग करने का निर्णय लेते समय सीमाओं पर विचार करें।

अंतर्निहित रूपांतरण कैसे प्रदर्शन करता है

इस बिंदु पर, आपको यह देखने में सक्षम होना चाहिए कि मैं डेटा परिवर्तित करने के लिए CAST() जैसे कार्यों के उपयोग की अनुशंसा करता हूं। और इस खंड में, आप देखेंगे कि क्यों।

WideWorldImporters . का उपयोग करके इस प्रश्न पर विचार करें माइक्रोसॉफ्ट से डेटाबेस। इसे क्रियान्वित करने से पहले, कृपया वास्तविक निष्पादन योजना शामिल करें . को सक्षम करें SQL सर्वर प्रबंधन स्टूडियो . में ।

USE WideWorldImporters
GO
SELECT
[CustomerID]
,[OrderID]
,[OrderDate]
,[ExpectedDeliveryDate]
FROM [Sales].[Orders]
WHERE [CustomerID] like '487%'

ऊपर की क्वेरी में, हम [CustomerID . के साथ बिक्री ऑर्डर के परिणाम को फ़िल्टर करते हैं ] '487%' की तरह। यह केवल यह प्रदर्शित करने के लिए है कि int . के निहित रूपांतरण का क्या प्रभाव पड़ता है डेटा प्रकार varchar . पर है ।

इसके बाद, हम नीचे दी गई निष्पादन योजना की जांच करते हैं:

जैसा कि आप देख सकते हैं, चयन . में एक चेतावनी है चिह्न। इसलिए, टूलटिप देखने के लिए अपने माउस को घुमाएं। इसके बाद, चेतावनी संदेश पर ध्यान दें, अर्थात् CONVERT_IMPLICIT ।

इससे पहले कि हम आगे बढ़ें, यह CONVERT_IMPLICIT चेतावनी तब होती है जब SQL सर्वर के लिए एक अंतर्निहित रूपांतरण करना आवश्यक होता है। आइए समस्या पर करीब से नज़र डालें। जैसा कि नीचे बताया गया है, चेतावनी के 2 भाग हैं:

• CONVERT_IMPLICIT क्वेरी प्लान के चुनाव में "कार्डिनैलिटी एस्टीमेट" को प्रभावित कर सकता है।
• CONVERT_IMPLICIT क्वेरी योजना के चुनाव में “सीकप्लान” को प्रभावित कर सकता है।

ये दोनों संकेत देते हैं कि आपकी क्वेरी धीमी चलेगी। लेकिन हम जानते हैं क्यों, बिल्कुल। हम जानबूझकर एक LIKE . का उपयोग करके एक अंतर्निहित रूपांतरण को बाध्य करते हैं पूर्णांक मान के लिए ऑपरेटर।

इसमें क्या बात है?

• डेटा के निहित रूपांतरण के कारण SQL सर्वर CONVERT_IMPLICIT का उपयोग करता है , जो आपके क्वेरी निष्पादन को धीमा कर देता है।
• इस समस्या को ठीक करने के लिए, अंतर्निहित रूपांतरण के उपयोग को समाप्त करें। हमारे मामले में, हमने [CustomerID . का इस्तेमाल किया ] पसंद करें '487%', हम [CustomerID . को बदलकर इसे ठीक कर सकते हैं ] =487. क्वेरी को ठीक करने से क्वेरी निष्पादन योजना बदल जाएगी, पहले की चेतावनी हटा दी जाएगी, और इंडेक्स स्कैन ऑपरेटर को इंडेक्स सीक में बदल दिया जाएगा। अंत में, प्रदर्शन में सुधार होता है।

सुखद अंत? हाँ!

टेकअवे

जैसा कि दिखाया गया है, हम केवल SQL सर्वर को एक अंतर्निहित रूपांतरण के साथ परिवर्तित नहीं करने दे सकते। मैं अनुशंसा करता हूं कि डेटा परिवर्तित करते समय क्या उपयोग करना है, यह तय करते समय आप पूर्वता का पालन करें।

• सबसे पहले, अगर आपको बस वैसे ही रूपांतरित करने की आवश्यकता है, तो कास्ट . का उपयोग करें ()। जब अन्य आरडीबीएम को पोर्ट करने का संबंध है तो यह एक अधिक मानकीकृत कार्य है।
• दूसरा, यदि आपको स्वरूपित डेटा की आवश्यकता है, तो रूपांतरित करें . का उपयोग करें ()।
• तीसरा, यदि दोनों कास्ट करें () और बदलें () काम करने में विफल, PARSE का उपयोग करें ()।
• अंत में, कनवर्ट करते समय त्रुटियों का परीक्षण करने के लिए, TRY_CAST का उपयोग करें (), TRY_CONVERT (), या TRY_PARSE ()।

खैर, अभी के लिए काफी है। मुझे उम्मीद है कि यह आपके अगले कोडिंग एडवेंचर्स में आपकी मदद करेगा। एक पैर तोड़ दो!

Microsoft से SQL डेटा रूपांतरण के विषय पर अधिक जानने के लिए:

• कास्ट और कन्वर्ट करें
• पार्स
• TRY_CAST, TRY_CONVERT, और TRY_PARSE