एसर सर्वर आटो-ट्रिम वर्कर मूल्य में बराबर तुलना में लेकिन तुलना की तरह नहीं

13

मैं SQL सर्वर पर कुछ दिलचस्प व्यवहार (2005 और 2012 में मनाया गया) में आया था, आज मुझे उम्मीद थी कि कोई समझा सकता है।

एक =NVARCHAR क्षेत्र पर उपयोग करने वाली एक क्वेरी स्ट्रिंग में अनुगामी स्थान (या तुलना से पहले ऑटो-ट्रिम किए गए मान) को likeअनदेखा करती है, लेकिन ऑपरेटर का उपयोग करने वाली एक ही क्वेरी ने अंतरिक्ष की अनदेखी नहीं की। 2012 में इस्तेमाल किया जा रहा Collation Latin1_General_CI_AS है।

इस SQL फिडेल पर विचार करें: http://sqlfiddle.com/# -6/72262/4

ध्यान दें कि likeऑपरेटर अनुगामी अंतरिक्ष स्ट्रिंग के लिए एक परिणाम नहीं लौटाता है, लेकिन =ऑपरेटर करता है। ऐसा क्यों है?

बोनस अंक: मैं इसे VARCHAR क्षेत्र पर दोहराने में असमर्थ हूं, मैंने सोचा होगा कि दोनों डेटा प्रकारों में एक स्थान को एक ही तरह से संभाला जाएगा - क्या यह सच है?

sql-server sql-server-2012

— WT_W
स्रोत

मैं एक चेक बाधा लिखने के लिए देख रहा था कि एक स्ट्रिंग छंटनी की गई थी। मुझे एक वर्कअराउंड मिला, जिसे यह जांचना है कि MyString+'x' = ltrim(rtrim(MyString))+'x'जैसा कि इस ब्लॉग पर

— default.kramer

15

मेरे आरंभिक उत्तर ने सुझाव दिया कि व्यवहार में अंतर के लिए ANSI_PADDING ध्वज को OFF पर सेट करना दोष हो सकता है। हालाँकि, यह गलत है; इस ध्वज का केवल भंडारण पर प्रभाव है, लेकिन समानता की तुलना नहीं है।

अंतर Microsoft के SQL मानक के कार्यान्वयन से उपजा है । मानक में कहा गया है कि समानता की जाँच करते समय, समानता ऑपरेटर के बाएँ और दाएँ दोनों तार को समान लंबाई का होना चाहिए । यह निम्नलिखित परिणाम बताते हैं:

insert into test_padding (varchar_clmn, nvarchar_clmn) values ('space ', 'nspace ')
go
-- equality for varchar column
select count(*) from test_padding where varchar_clmn = 'space' -- returns 1
select count(*) from test_padding where varchar_clmn = 'space ' -- returns 1
select count(*) from test_padding where varchar_clmn = 'space    ' --returns 1
-- equality for nvarchar column
select count(*) from test_padding where nvarchar_clmn = 'nspace' -- returns 1
select count(*) from test_padding where nvarchar_clmn = 'nspace ' -- returns 1
select count(*) from test_padding where nvarchar_clmn = 'nspace    ' --returns 1

LIKE ऑपरेटर अपने ऑपरेंड को पैड नहीं करता है। यह कॉलम VARCHARऔर NVARCHARकॉलम प्रकारों के लिए अलग-अलग व्यवहार करता है :

-- likeness for varchar column
select count(*) from test_padding where varchar_clmn like 'space' -- returns 1
select count(*) from test_padding where varchar_clmn like 'space ' -- returns 1
select count(*) from test_padding where varchar_clmn like 'space    ' -- returns 0
-- likeness for nvarchar column
select count(*) from test_padding where nvarchar_clmn like 'nspace' -- returns 0
select count(*) from test_padding where nvarchar_clmn like 'nspace ' -- returns 1
select count(*) from test_padding where nvarchar_clmn like 'nspace    ' -- returns 0

ASCII प्रकार के लिए LIKE ऑपरेटर का व्यवहार SQL सर्वर-विशिष्ट है; यूनिकोड प्रकार के लिए यह एएनएसआई-अनुरूप है।

— राल्फ
स्रोत

4

SQL एक युग में पैदा हुआ था जब अधिकांश डेटा प्रोसेसिंग भाषाओं ने हर क्षेत्र / चर के लिए निश्चित लंबाई का उपयोग किया था। अतिरिक्त स्थानों के साथ पाठ फ़ील्ड की स्वचालित पैडिंग भी उस चित्र का हिस्सा थी। उस व्यवहार के साथ लाइन करने के लिए, मूल SQL CHAR प्रकार को स्पष्ट रूप से इसके '=' ऑपरेटर के लिए परिभाषित किया गया था ताकि अनुगामी रिक्त स्थान को अनदेखा किया जा सके। (यदि आपको यह अजीब लगता है, तो मुझे एक सम्मोहक मामला दिखाएं जहां एक पाठ में संलग्न अनुगामी रिक्त स्थान का वास्तविक वास्तविक व्यावसायिक अर्थ है ।)

SQL CHAR प्रकार तब से सभी प्रकार के दिशा-निर्देशों में विकसित हुए हैं, लेकिन यह अकल्पनीय नहीं है कि कुछ और आधुनिक डेटा प्रकार अभी भी अपने ऐतिहासिक पूर्ववर्तियों से कुछ विशेषताओं को प्राप्त कर चुके हैं।

— इरविन स्माउट
स्रोत

"मुझे एक सम्मोहक मामला दिखाएं जहां एक पाठ में संलग्न रिक्त स्थान का वास्तविक वास्तविक व्यावसायिक अर्थ है" - कुछ कच्चे कंसोल आउटपुट और पूर्व-असुरक्षित XML टुकड़े जैसे व्हाट्सएप-महत्वपूर्ण डेटा को संग्रहीत करना।

— दाई

1

LIKE (Transact-SQL) के लिए प्रलेखन में , Microsoft लिखता है (जोर मेरा):

LIKE का उपयोग करके पैटर्न का मिलान

LIKE ASCII पैटर्न मिलान और यूनिकोड पैटर्न मिलान का समर्थन करता है। जब सभी तर्क ... ASCII वर्ण डेटा प्रकार हैं, तो ASCII पैटर्न मिलान किया जाता है। यदि कोई भी तर्क यूनिकोड डेटा प्रकार का है, तो सभी तर्कों को यूनिकोड में बदल दिया जाता है और यूनिकोड पैटर्न का मिलान किया जाता है। जब आप यूनिकोड डेटा का उपयोग करते हैं ... LIKE के साथ, अनुगामी रिक्त स्थान महत्वपूर्ण हैं; हालांकि, गैर-यूनिकोड डेटा के लिए, पीछे जाने वाले रिक्त स्थान महत्वपूर्ण नहीं हैं। यूनिकोड LIKE ISO मानक के अनुकूल है। ASCII LIKE SQL सर्वर के पुराने संस्करणों के साथ संगत है।

— मिशेल डी रुइटर
स्रोत