शायद आपने टी-एसक्यूएल PARSE()
का सामना किया हो , CAST()
, और CONVERT()
SQL सर्वर के साथ काम करते समय कार्य करता है और सोचता है कि क्या अंतर है। ऐसा लगता है कि तीनों कार्य एक ही काम करते हैं, लेकिन उनके बीच सूक्ष्म अंतर हैं।
इस लेख में मेरा लक्ष्य इन कार्यों के बीच मुख्य अंतरों को रेखांकित करना है।
तुलना
यहां एक तालिका है जो CONVERT()
. के बीच मुख्य अंतरों को रेखांकित करती है , CAST()
, और PARSE()
SQL सर्वर में कार्य करता है:
कन्वर्ट () | कास्ट () | पार्स () | |
---|---|---|---|
आधिकारिक परिभाषा | एक डेटा प्रकार की अभिव्यक्ति को दूसरे डेटा प्रकार में रूपांतरित करता है। | एक डेटा प्रकार की अभिव्यक्ति को दूसरे डेटा प्रकार में रूपांतरित करता है। | SQL सर्वर में अनुरोधित डेटा प्रकार में अनुवादित व्यंजक का परिणाम देता है। |
स्वीकृत मान | कोई मान्य व्यंजक. | कोई मान्य व्यंजक. | स्ट्रिंग. |
रिटर्न वैल्यू | दूसरा तर्क, अनुरोधित डेटा प्रकार में अनुवादित जैसा कि पहले तर्क द्वारा प्रदान किया गया है। | पहला तर्क, दूसरे तर्क द्वारा प्रदान किए गए अनुरोधित डेटा प्रकार में अनुवादित। | पहला तर्क, दूसरे तर्क द्वारा प्रदान किए गए अनुरोधित डेटा प्रकार में अनुवादित। |
समर्थित रूपांतरण | किन्हीं दो डेटा प्रकारों के बीच। | किन्हीं दो डेटा प्रकारों के बीच। | केवल स्ट्रिंग से दिनांक/समय और संख्या प्रकारों तक। |
शैलीस्वीकार करता है तर्क? | हां। | नहीं. | नहीं. |
संस्कृति को स्वीकार करता है तर्क? | नहीं. | नहीं. | हां। |
.NET फ्रेमवर्क की आवश्यकता है? | नहीं. | नहीं. | हां। |
उपरोक्त तालिका के अतिरिक्त कुछ अन्य बिंदु:
- माइक्रोसॉफ्ट के दस्तावेज बताते हैं कि
PARSE()
रिमोट नहीं किया जाएगा (क्योंकि यह सीएलआर की उपस्थिति पर निर्भर करता है)। सीएलआर की आवश्यकता वाले फ़ंक्शन को हटाने से दूरस्थ सर्वर पर त्रुटि हो सकती है। - कुछ मान हैं जो
PARSE()
से निपट सकते हैं लेकिनCAST()
औरCONVERT()
नहीं कर सकता (उदाहरण के लिए, निश्चित तिथि प्रारूपों का उपयोग करने वाले तार)। CAST()
ANSI SQL-92 मानक में शामिल है।- कुछ लोगों का तर्क है कि
CAST()
अन्य दो की तुलना में बेहतर प्रदर्शन है। - स्ट्रिंग मानों को पार्स करते समय एक निश्चित प्रदर्शन ओवरहेड होता है। इसलिए,
PARSE()
आम तौर पर अन्य दो की तुलना में धीमी गति से चलेगी।
नीचे उन स्थितियों के उदाहरण दिए गए हैं जहां प्रत्येक फ़ंक्शन सबसे उपयुक्त होगा।
CAST का उपयोग कब करें ()
CAST()
. का उपयोग करने के लिए एक अच्छा तर्क दिया जा सकता है किसी भी परिदृश्य के लिए जो नीचे सूचीबद्ध नहीं है। जैसा कि बताया गया है, CAST()
SQL-92 के बाद से ANSI SQL मानक का हिस्सा रहा है, इसलिए इसे विभिन्न DBMS (यदि यह एक आवश्यकता है) के बीच अधिक पोर्टेबल होना चाहिए।
साथ ही, कुछ लोगों का तर्क है कि CAST()
अन्य दो की तुलना में बेहतर प्रदर्शन है (यहां एक दिलचस्प लेख है जो तीनों कार्यों के बीच प्रदर्शन की तुलना करता है)।
हालांकि, कुछ मान्य कारण भी हैं जिन्हें आप उपयोग करना पसंद कर सकते हैं (या आवश्यकता है) CONVERT()
CAST()
से अधिक ।
कन्वर्ट का उपयोग कब करें ()
CONVERT()
फ़ंक्शन तब काम आ सकता है जब आपको style
. का उपयोग करने की आवश्यकता हो यह निर्दिष्ट करने के लिए तर्क कि दिनांक और स्ट्रिंग के बीच कनवर्ट करते समय दिनांक को कैसे स्वरूपित किया जाना चाहिए। यहां कुछ उदाहरण दिए गए हैं:
DECLARE @date datetime2 = '2018-06-07 02:35:52.8537677'; SELECT CONVERT(nvarchar(30), @date, 100) AS '100', CONVERT(nvarchar(30), @date, 101) AS '101', CONVERT(nvarchar(30), @date, 102) AS '102', CONVERT(nvarchar(30), @date, 103) AS '103';
परिणाम:
+---------------------+------------+------------+------------+ | 100 | 101 | 102 | 103 | |---------------------+------------+------------+------------| | Jun 7 2018 2:35AM | 06/07/2018 | 2018.06.07 | 07/06/2018 | +---------------------+------------+------------+------------+
आप इसे केवल CONVERT()
with के साथ ही कर सकते हैं क्योंकि:
CAST()
style
का समर्थन नहीं करता बहस; औरPARSE()
दिनांक/समय से स्ट्रिंग मान में परिवर्तित नहीं होता है (यहstyle
का भी समर्थन नहीं करता है तर्क)
PARSE() का उपयोग कब करें
इस फ़ंक्शन के विभिन्न नुकसान (प्रदर्शन, .NET पर निर्भरता, सीमित डेटा प्रकार रूपांतरण) के बावजूद, इसके कुछ फायदे भी हैं, और कुछ परिदृश्य हैं जहां यह आपकी एकमात्र पसंद हो सकती है। उदाहरण के लिए, एक तारीख प्रदान करते समय जिसमें कार्यदिवस का नाम शामिल हो, जैसे शुक्रवार, 20 जुलाई 2018 ।
जब अन्य कोई त्रुटि लौटाते हैं
यहां ऐसे उदाहरण दिए गए हैं जहां PARSE()
तीनों में से यही एकमात्र कार्य है जो बिना किसी त्रुटि के मान को सफलतापूर्वक परिवर्तित कर सकता है।
इन उदाहरणों में, हम विभिन्न स्ट्रिंग मानों को तारीख . में बदलने का प्रयास करते हैं डेटा प्रकार। हालांकि, हमारे द्वारा प्रदान किए जाने वाले स्ट्रिंग मानों में कार्यदिवस का नाम शामिल होता है। यह CAST()
के लिए समस्याएँ उत्पन्न करता है और CONVERT()
, लेकिन PARSE()
कोई समस्या नहीं है।
PARSE()
SELECT PARSE('Friday, 20 July 2018' AS date) AS 'Result 1', PARSE('Fri, 20 July 2018' AS date) AS 'Result 2', PARSE('Friday 20 July 2018' AS date) AS 'Result 3';
परिणाम:
+------------+------------+------------+ | Result 1 | Result 2 | Result 3 | |------------+------------+------------| | 2018-07-20 | 2018-07-20 | 2018-07-20 | +------------+------------+------------+
तो PARSE()
हमारे द्वारा प्रदान की जाने वाली तिथि के प्रारूप में कोई समस्या नहीं है।
कन्वर्ट ()
SELECT CONVERT(date, 'Friday, 20 July 2018') AS 'Result 1', CONVERT(date, 'Fri, 20 July 2018') AS 'Result 2', CONVERT(date, 'Friday 20 July 2018') AS 'Result 3';
परिणाम:
Conversion failed when converting date and/or time from character string.
तो CONVERT()
स्ट्रिंग को इस तरह के प्रारूप में बदलने में असमर्थ है।
कास्ट ()
SELECT CAST('Friday, 20 July 2018' AS date) AS 'Result 1', CAST('Fri, 20 July 2018' AS date)AS 'Result 2', CAST('Friday 20 July 2018' AS date) AS 'Result 3';
परिणाम:
Conversion failed when converting date and/or time from character string.
और CAST()
वही त्रुटि देता है।
इसलिए यदि आप पाते हैं कि अन्य दो कार्यों में त्रुटियां हो रही हैं, तो PARSE()
आज़माएं इसके बजाय।
संस्कृति निर्दिष्ट करना
एक अन्य परिदृश्य जहां आप PARSE()
. का उपयोग करना पसंद कर सकते हैं फ़ंक्शन उस संस्कृति/भाषा को निर्दिष्ट करते समय होता है जिसमें स्ट्रिंग प्रदान की जाती है। PARSE()
एक वैकल्पिक तर्क है जो आपको यह निर्दिष्ट करने की अनुमति देता है कि किस संस्कृति का उपयोग करना है। यदि छोड़ा गया है, तो वर्तमान सत्र की भाषा का उपयोग किया जाता है।
culture
. को शामिल करने का उदाहरण तर्क:
SELECT PARSE('07/01/2018' AS date USING 'en-US') AS 'Result 1', PARSE('07/01/2018' AS date USING 'de-DE') AS 'Result 2';
परिणाम:
+------------+------------+ | Result 1 | Result 2 | |------------+------------| | 2018-07-01 | 2018-01-07 | +------------+------------+
एक संस्कृति विकल्प
संस्कृति को PARSE()
. के साथ निर्दिष्ट करने में सक्षम होने के लाभ के बावजूद , आपके पास भाषा सेटिंग बदलने की क्षमता है, जिसका अर्थ है कि आप CAST()
का उपयोग करते समय समान प्रभाव प्राप्त कर सकते हैं या CONVERT()
।
उदाहरण के लिए, SET LANGUAGE us_english
. का उपयोग करना क्वेरी से पहले वर्तमान भाषा सेटिंग को us_english . में बदल देगी . हालांकि यह आपको क्वेरी के भीतर विभिन्न संस्कृतियों को निर्दिष्ट करने की अनुमति नहीं देता है (जैसे उपरोक्त उदाहरण में), यह पूरी क्वेरी (और किसी भी बाद के प्रश्नों) को प्रभावित करता है।
आप इसी तरह दिनांक स्वरूप सेटिंग भी बदल सकते हैं। उदाहरण के लिए, SET DATEFORMAT mdy
।
CAST()
. के साथ क्वेरी चलाने से पहले भाषा सेटिंग बदलने का एक उदाहरण यहां दिया गया है और CONVERT()
:
जर्मन:
SET LANGUAGE German; SELECT CONVERT(date, '07/01/2018') AS 'Convert'; SELECT CAST('07/01/2018' AS date) AS 'Cast';
परिणाम:
+------------+ | Convert | |------------| | 2018-01-07 | +------------+ Die Spracheneinstellung wurde in Deutsch geändert. +------------+ | Cast | |------------| | 2018-01-07 | +------------+
us_english:
SET LANGUAGE us_english; SELECT CONVERT(date, '07/01/2018') AS 'Convert'; SELECT CAST('07/01/2018' AS date) AS 'Cast';
परिणाम:
+------------+ | Convert | |------------| | 2018-07-01 | +------------+ Changed language setting to us_english. +------------+ | Cast | |------------| | 2018-07-01 | +------------+
याद रखें, जब आप ऐसा करते हैं, तो आप सत्र के लिए भाषा/दिनांक स्वरूप परिवेश बदल रहे होते हैं। इसे वापस बदलना न भूलें!