डेटाबेस डिफ़ॉल्ट कोलाजेशन को बदलते समय Latin1_General_BIN प्रदर्शन प्रभाव

16

Latin1_General_BINस्ट्रिंग तुलनात्मक रूप से संवेदनशील बनाने के लिए , मैंने डेटाबेस कोलेशन को सेट किया है । क्या इससे प्रदर्शन पर असर पड़ेगा? क्या इसका डेटाबेस में डीएमएल या डीडीएल संचालन पर कोई प्रभाव पड़ेगा? डेटाबेस पहले से ही इसमें तालिकाओं के साथ मौजूद है।

sql-server  sql-server-2008-r2  performance-tuning  collation  unicode 
— राकेश
स्रोत

जवाबों:

24

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

मनुष्य आमतौर पर यह नहीं पाते हैं कि द्विआधारी टकराव छँटाई और तुलनात्मक व्यवहार का उत्पादन करते हैं जो वे अपेक्षा करते हैं। इसलिए, हालांकि ये सबसे अच्छा प्रदर्शन (विशेष रूप से शुद्ध कोड-पॉइंट BIN2 संस्करण) प्रदान करते हैं, अधिकांश कार्यान्वयन उनका उपयोग नहीं करते हैं।

कच्चे प्रदर्शन के मामले में अगला (लेकिन केवल गैर-यूनिकोड स्ट्रिंग्स के लिए) पिछड़े-अनुकूलता वाले SQL कोलाजेशन हैं । यूनिकोड डेटा के साथ काम करते समय, ये कोलाज उसी प्रदर्शन विशेषताओं के साथ, बजाय विंडोज कोलाजेशन का उपयोग करते हैं । यहां सूक्ष्म जाल हैं, इसलिए आपको इन दिनों SQL कोलाज चुनने के लिए अच्छे कारणों की आवश्यकता है (जब तक कि यह यूएस सिस्टम पर काम नहीं करता है, जहां यह अभी भी डिफ़ॉल्ट है)।

सामान्य रूप से, यूनिकोड की तुलना और छँटाई के नियमों के कारण, विंडोज कोलाज सबसे धीमे हैं। फिर भी, ये SQL सर्वर में विंडोज के साथ पूर्ण संगतता प्रदान करते हैं, और यूनिकोड मानक में बदलाव के साथ बनाए रखने के लिए नियमित रूप से बनाए रखा जाता है। आधुनिक उपयोग के लिए जिसमें यूनिकोड डेटा शामिल है, आमतौर पर एक विंडोज कोलेशन की सिफारिश की जाती है।

टी एल; डॉ

यदि आप चाहते हैं कि केस-संवेदी तुलना और सॉर्टिक्स की छंटनी हो, तो आपको _CS_जो भी आधार टकराव के लिए (केस सेंसिटिव के लिए) बदलाव का चयन करना चाहिए, आपके उपयोगकर्ताओं की भाषा और संस्कृति के लिए अपेक्षित व्यवहार प्रदान करता है। उदाहरण के लिए, ये दोनों केस-सेंसिटिव कॉलेशन हैं:

-- Latin1-General, case-sensitive, accent-sensitive
Latin1_General_CS_AS 

-- Latin1-General, case-sensitive, accent-sensitive for Unicode Data, 
-- SQL Server Sort Order 51 on Code Page 1252 for non-Unicode Data
SQL_Latin1_General_CP1_CS_AS

आप इन परिभाषाओं को sys.fn_helpcollations का उपयोग करके देख सकते हैं

उदाहरण

चार तालिकाओं जो बिल्कुल समान हैं सिवाय टकराव के; एक बाइनरी, एक केस-संवेदी, एक केस-असंवेदनशील और एक SQL केस-सेंसिटिव:

CREATE TABLE #Example_BIN
(
    string nvarchar(50) 
        COLLATE Latin1_General_BIN
        NOT NULL
);

CREATE TABLE #Example_CS
(
    string nvarchar(50) 
        COLLATE Latin1_General_CS_AI
        NOT NULL
);

CREATE TABLE #Example_CI
(
    string nvarchar(50) 
        COLLATE Latin1_General_CI_AI
        NOT NULL
);

CREATE TABLE #Example_SQL
(
    string varchar(50) -- Note varchar
        COLLATE SQL_Latin1_General_CP1_CS_AS
        NOT NULL
);

प्रत्येक तालिका के लिए एक ही नमूना डेटा :

INSERT #Example_BIN
    (string)
VALUES
    (N'A'),
    (N'a'),
    (N'B'),
    (N'b'),
    (N'C'),
    (N'c');

INSERT #Example_CS
SELECT EB.string 
FROM #Example_BIN AS EB;

INSERT #Example_CI
SELECT EB.string 
FROM #Example_BIN AS EB;

INSERT #Example_SQL
SELECT EB.string 
FROM #Example_BIN AS EB;

अब हम 'a' से अधिक स्ट्रिंग्स ढूंढना चाहते हैं :

SELECT EB.string AS BIN
FROM #Example_BIN AS EB
WHERE EB.string > N'a'
ORDER BY EB.string;

SELECT EC.string AS CS
FROM #Example_CS AS EC
WHERE EC.string > N'a'
ORDER BY EC.string;

SELECT EC2.string AS CI
FROM #Example_CI AS EC2
WHERE EC2.string > N'a'
ORDER BY EC2.string;

SELECT ES.string AS SQL
FROM #Example_SQL AS ES
WHERE ES.string > 'a' -- not Unicode
ORDER BY ES.string;

परिणाम:

╔═════╗
║ BIN ║
╠═════╣
║ b   ║
║ c   ║
╚═════╝

╔════╗
║ CS ║
╠════╣
║ A  ║
║ b  ║
║ B  ║
║ c  ║
║ C  ║
╚════╝

╔════╗
║ CI ║
╠════╣
║ B  ║
║ b  ║
║ C  ║
║ c  ║
╚════╝

╔═════╗
║ SQL ║
╠═════╣
║ B   ║
║ b   ║
║ C   ║
║ c   ║
╚═════╝

आखिरकार...

हालाँकि, अगर हम यूनिकोड शाब्दिक का उपयोग एसक्यूएल कोलेशन के साथ करते हैं, तो निहित रूपांतरण नियमों का परिणाम विंडोज कॉलेशन तुलना में होता है:

SELECT ES.string AS SQL
FROM #Example_SQL AS ES
WHERE ES.string > N'a'
ORDER BY ES.string;

... और SQL कोलाज परिणाम बदल जाते हैं :

╔═════╗
║ SQL ║
╠═════╣
║ A   ║
║ B   ║
║ b   ║
║ C   ║
║ c   ║
╚═════╝
— पॉल व्हाइट को फिर से बहाल मोनिका
स्रोत
10

यह देखते हुए कि यह एक मौजूदा डेटाबेस है जिसमें पहले से ही टेबल परिभाषित है, डेटाबेस कोलाज को बदलने की कार्रवाई के लिए कुछ बहुत ही गंभीर निहितार्थ हैं, जो कि संभावित प्रदर्शन प्रभाव से परे DML opertions (जो वास्तव में पहले से ही था)। प्रदर्शन और कार्यक्षमता पर बहुत वास्तविक प्रभाव पड़ता है, और यह परिवर्तन न केवल इच्छित लक्ष्य (कम से कम लगातार नहीं) को प्राप्त नहीं किया, बल्कि जैसा कि व्यवहार में बदलाव की संभावना है (या नई तालिकाओं के निर्माण के समय व्यवहार में परिवर्तन करेगा) कैसे डेटा का आदेश दिया और समान है।

पॉल ने पहले से ही अपने जवाब में विभिन्न प्रकार के टकरावों के बीच प्रदर्शन और व्यवहार में अंतर की अच्छी व्याख्या और उदाहरण प्रदान किए हैं, इसलिए मैं यहां नहीं दोहराऊंगा। हालांकि, कुछ बिंदुओं को कुछ अतिरिक्त विवरण की आवश्यकता होती है, और एक नए DB के टकराव को स्थापित करने के विपरीत, मौजूदा DB के टकराव को बदलने के वर्तमान परिदृश्य के संबंध में जोड़ने के लिए कई अन्य बिंदु हैं।

  1. द्विआधारी टकराव सिर्फ केस-संवेदी से अधिक हैं: वे सब कुछ संवेदनशील हैं! तो, एक बाइनरी कॉलेशन का उपयोग करके (में _BINया समाप्त हो रहा है )_BIN2 ), आपके तुलना अब भी संवेदनशील, काना, संवेदनशील चौड़ाई संवेदनशील उच्चारण रहे हैं, और संभावित रूप से संवेदनशील लस (कम से कम है कि इन दिनों प्रवृत्ति प्रतीत हो रहा है ;-))। क्या यह परिवर्तन करने का वांछित प्रभाव था? क्या अंत-उपयोगकर्ता व्यवहार के इस बदलाव की उम्मीद कर रहे हैं?

  2. टकराव न केवल तुलना को प्रभावित करते हैं, बल्कि छँटाई भी करते हैं। एक द्विआधारी मिलान प्रकार के आधार पर होगा ASCIIया UNICODEबाइट मूल्य (पर निर्भर करता है VARCHARया NVARCHARप्रत्येक की, क्रमशः) बाइट । इसलिए, एक द्विआधारी टकराव का चयन करके आप भाषा-संस्कृति / विशिष्ट वेटिंग नियमों को छोड़ रहे हैं जो उस संस्कृति के वर्णमाला के अनुसार प्रत्येक वर्ण (यहां तक ​​कि कुछ भाषा में वर्ण, जैसे कि हंगरी, जिसमें 2 अक्षर शामिल हैं) का आदेश देते हैं। तो, अगर "ch" स्वाभाविक रूप से "k" के बाद आना चाहिए , ठीक है, कि बाइनरी कॉलेशन का उपयोग करने वाला नहीं है। फिर, क्या यह परिवर्तन करने का वांछित प्रभाव था? क्या अंत-उपयोगकर्ता व्यवहार के इस बदलाव की उम्मीद कर रहे हैं?

  3. जब तक आपके पास अपने आवेदन के लिए विशिष्ट बैकवर्ड-संगतता आवश्यकताएं नहीं हैं, तब तक आपको निश्चित रूप से, टकराव के BIN2बजाय का उपयोग करना चाहिए BIN, यह मानते हुए कि आप पहले स्थान पर द्विआधारी टकराव चाहते हैं। BIN2Collations SQL सर्वर 2005 में शुरू की गई है, और के लिए MSDN पेज के अनुसार कर रहे थे बिन और BIN2 collations का उपयोग करने के लिए दिशानिर्देश :

    SQL सर्वर में पिछले बाइनरी टकराव, "_BIN" के साथ समाप्त होने वाले, यूनिकोड डेटा के लिए एक अपूर्ण कोड-पॉइंट-टू-कोड-पॉइंट तुलना करते हैं। पुराने SQL सर्वर बाइनरी टकराव WCHAR के रूप में पहले चरित्र की तुलना में, एक बाइट द्वारा-बाइट तुलना के बाद।

    ...

    आप वास्तविक कोड-पॉइंट तुलनाओं का लाभ उठाने के लिए [_BIN2] बाइनरी कोलाज में माइग्रेट कर सकते हैं, और आपको नए अनुप्रयोगों के विकास के लिए नए बाइनरी कॉलेशन का उपयोग करना चाहिए।

    यह भी ध्यान दिया जाना चाहिए कि टकराव StringComparison Enumeration_BIN2 के Ordinalविकल्प के व्यवहार से आसानी से मेल खाते हैं , जैसे कि .NET और उस विकल्प का उपयोग करके .NET कोड में किए गए छंटनी के समान परिणाम प्राप्त होंगे, जो SQL सर्वर के भीतर किए जा रहे समान संचालन (उपयोग करते समय) collations, निश्चित रूप से)।_BIN2

  4. _BIN2टकरावों के संबंध में जो कुछ कहा गया है, उसके समान कारणों के लिए , जब तक कि आपके पास पश्चगामी-संगतता व्यवहार बनाए रखने के लिए विशिष्ट आवश्यकताएं नहीं हैं, आपको Windows collations का उपयोग करने की ओर झुकना चाहिए, न कि SQL सर्वर-विशिष्ट collations (अर्थात जो SQL_अब शुरू होने वाले हैं) पर विचार किया जाता है थोड़े "चूसा" ;-))।

  5. यूनिकोड डेटा का उपयोग करते समय (यानी स्ट्रिंग के साथ उपसर्ग Nया जहां डेटाप्रकार के रूप में निर्दिष्ट किया गया है अनुप्रयोग कोड से एसक्यूएल सर्वर में आ रहा है NCharया NVarChar), मैं नहीं दिख रहा है कि कैसे एक और बनाम एक मिलान का उपयोग कर डालने या अपडेट करते हुए एक के लिए एक फर्क होता NCHARयाNVARCHAR स्ट्रिंग फ़ील्ड ।

    गैर-यूनिकोड डेटा का उपयोग कर, या में डालने या एक गैर-यूनिकोड क्षेत्र है, तो विशेष रूप से मिलान (डेटाबेस या क्षेत्र) को अपडेट करते समय हो सकता है अगर कोई भी वर्ण डाला जा रहा है / अद्यतन की जरूरत एक छोटी सी भूमिका खेलने अनुवाद किया जाना है, या mapable नहीं हैं (है यह भी एक शब्द?), कोड पृष्ठ द्वारा निर्दिष्ट किया गया है जो कि समतलीकरण द्वारा परिभाषित किया गया है। बेशक, यह संभावित मुद्दा मौजूद है जब भी कोई गैर-यूनिकोड डेटा या डेटा प्रकारों का उपयोग कर रहा है, और डीबी टकराव को बदलने के इस परिदृश्य के लिए विशिष्ट नहीं है। यह परिवर्तन स्ट्रिंग शाब्दिकों को प्रभावित करेगा (जो कि पहले से ही एक मुद्दा हो सकता है यदि DB टकराव क्षेत्र के टकराव से अलग था)। लेकिन भले ही DB परिवर्तन के लिए कोई परिवर्तन नहीं किया गया हो, अन्य DBs या SQL सर्वर (किसी भी क्लाइंट कोड) के बाहर से आने वाला डेटा किसी भी वर्ण और किसी विशेष एन्कोडिंग का हो सकता है।

  6. बहोत महत्वपूर्ण!!! डेटाबेस डिफ़ॉल्ट कोलाजेशन को बदलते समय, किसी भी मौजूदा टेबल्स में किसी भी मौजूदा स्ट्रिंग फ़ील्ड के लिए निर्दिष्ट किया गया कॉलेशन नहीं बदलेगा, लेकिन किसी भी नए फ़ील्ड में डेटाबेस डिफ़ॉल्ट (जब तक कि ओवरराइड के माध्यम से ओवरराइड नहीं किया जाता है)COLLATE क्लॉज के ) का । यह आपके प्रश्नों को तीन तरीकों से प्रभावित करेगा:

    1) यदि कोई प्रश्न उन मौजूदा क्षेत्रों में से किसी भी नए फ़ील्ड में शामिल हो, तो आपको एक कोलाज मिसमैच त्रुटि मिलेगी:

    USE [master];
GO

IF (DB_ID(N'ChangeCollationTest') IS NOT NULL)
BEGIN
    PRINT 'Dropping [ChangeCollationTest] DB...';
    ALTER DATABASE [ChangeCollationTest]
        SET SINGLE_USER
        WITH ROLLBACK IMMEDIATE;

    DROP DATABASE [ChangeCollationTest];
END;
GO

PRINT 'Creating [ChangeCollationTest] DB...';
CREATE DATABASE [ChangeCollationTest]
    COLLATE SQL_Latin1_General_CP1_CI_AS;
GO

USE [ChangeCollationTest];
GO

CREATE TABLE [CollateTest-SQL_Latin1_General_CP1_CI_AS]
             (Col1 NVARCHAR(50) COLLATE DATABASE_DEFAULT, Col2 NVARCHAR(50));
SELECT *
FROM   sys.columns sc
WHERE  sc.[object_id] = OBJECT_ID(N'[CollateTest-SQL_Latin1_General_CP1_CI_AS]');
-- "collation_name" for both fields shows: SQL_Latin1_General_CP1_CI_AS
GO

USE [master];
GO
ALTER DATABASE [ChangeCollationTest]
    COLLATE Latin1_General_BIN2;
GO
USE [ChangeCollationTest];
GO

CREATE TABLE [CollateTest-Latin1_General_BIN2]
             (Col1 NVARCHAR(50) COLLATE DATABASE_DEFAULT, Col2 NVARCHAR(50));
SELECT *
FROM   sys.columns sc
WHERE  sc.[object_id] = OBJECT_ID(N'[CollateTest-Latin1_General_BIN2]');
-- "collation_name" for both fields shows: Latin1_General_BIN2
GO


SELECT *
FROM   dbo.[CollateTest-SQL_Latin1_General_CP1_CI_AS] ctSQL
INNER JOIN  dbo.[CollateTest-Latin1_General_BIN2] ctWIN
        ON  ctWIN.Col1 = ctSQL.Col1;

    यह दिखाता है:

    Msg 468, Level 16, State 9, Line 4
Cannot resolve the collation conflict between "SQL_Latin1_General_CP1_CI_AS" and
"Latin1_General_BIN2" in the equal to operation.

    2) मौजूदा तालिकाओं के मौजूदा क्षेत्रों (पूर्व डिफ़ॉल्ट टकराव के लिए सेट ) पर Predicates / फिल्टर जो स्ट्रिंग शाब्दिक या चर की तुलना में त्रुटि नहीं करेंगे, लेकिन एसक्यूएल सर्वर की समतुल्यता को समतुल्य करने की आवश्यकता के कारण वे प्रदर्शन-वार प्रभावित हो सकते हैं। दोनों तरफ और स्वचालित रूप से स्ट्रिंग शाब्दिक या चर क्षेत्र के समतलीकरण के लिए परिवर्तित करना। "वास्तविक निष्पादन योजना शामिल करें" (नियंत्रण-एम) को सक्षम करें और फिर निम्नलिखित को निष्पादित करें (यह मानते हुए कि आपने पहले से ही ऊपर दिखाए गए प्रश्नों को चलाया है):

    SELECT *
FROM   dbo.[CollateTest-SQL_Latin1_General_CP1_CI_AS] ctSQL
WHERE  ctSQL.Col1 = N'a';
-- Unspecified collations on string literals and variables assume the database default
-- collation. This mismatch doesn't cause an error because SQL Server adds a
-- "[Col1]=CONVERT_IMPLICIT(nvarchar(4000),[@1],0)" but it can hurt performance.

SELECT *
FROM   dbo.[CollateTest-Latin1_General_BIN2] ctWIN
WHERE  ctWIN.Col1 = N'a';
-- No CONVERT_IMPLICIT; plan shows "[Col1]=[@1]".

    3) और, अंतर्निहित रूपांतरणों की बात करते हुए, ध्यान दें कि यह स्ट्रिंग शाब्दिक कैसे है (डेटाबेस डिफ़ॉल्ट टकराव के एक निहित टकराव के साथ Latin1_General_BIN2) : जो परिवर्तित है, तालिका में फ़ील्ड नहीं । कोई भी अनुमान लगाता है कि क्या यह फ़िल्टर केस-असंवेदनशील (पुराना टकराव) या केस-सेंसिटिव (नया टकराव) होगा? देखने के लिए निम्नलिखित चलाएँ:

    INSERT INTO dbo.[CollateTest-SQL_Latin1_General_CP1_CI_AS] (Col1)
VALUES (N'a'), (N'A');

SELECT ctSQL.Col1
FROM   dbo.[CollateTest-SQL_Latin1_General_CP1_CI_AS] ctSQL
WHERE  ctSQL.Col1 = N'a';

    यह दिखाता है:

    Col1
----
a
A

    डी 'ओह! इतना ही नहीं इस क्वेरी के लिए एक मामूली (या शायद अधिक महत्वपूर्ण?) प्रदर्शन हिट हैCONVERT_IMPLICIT() , लेकिन यह वांछित केस-संवेदी तरीके से व्यवहार भी नहीं करता है।

    एर्गो, यदि टकराव को एक डीबी पर बदल दिया जाता है जिसमें पहले से ही टेबल है, तो हां, प्रदर्शन और कार्यक्षमता दोनों प्रभावित होते हैं।

    यदि एक नए DB पर टकराव को सेट किया जा रहा है, तो पॉल ने पहले से ही कवर किया है कि यह समझाते हुए कि कैसे बाइनरी टकराव, जबकि तेजी से, शायद उस तरह से सॉर्ट नहीं करेगा जिसकी कोई उम्मीद करेगा या इच्छा करेगा।

यह भी ध्यान दिया जाना चाहिए कि आप हमेशा प्रति शर्त टकराव निर्दिष्ट कर सकते हैं। मुक़ाबला खंड में जोड़ा जा सकता WHEREकी स्थिति, ORDER BYहै, और सबसे किसी भी जगह है कि एक स्ट्रिंग स्वीकार करता है।

उदाहरण 1 (WHERE की स्थिति):

SELECT tmp.col AS [SQL-CaseSensitive]
FROM (VALUES ('a'), ('A'), ('b'), ('B')) tmp(col)
WHERE tmp.col > 'a' COLLATE SQL_Latin1_General_CP1_CS_AS;

SELECT tmp.col AS [Windows-CaseSensitive]
FROM (VALUES ('a'), ('A'), ('b'), ('B')) tmp(col)
WHERE tmp.col > 'a' COLLATE Latin1_General_CS_AI;

यह दिखाता है:

SQL-CaseSensitive
-----------------
b
B

Windows-CaseSensitive
-----------------
A
b
B

उदाहरण 2 (आदेश द्वारा):

SELECT tmp.col AS [Windows-CaseSensitive]
FROM (VALUES ('a'), ('A'), ('b'), ('B')) tmp(col)
ORDER BY tmp.col COLLATE Latin1_General_CS_AI;

SELECT tmp.col AS [Windows-Binary]
FROM (VALUES ('a'), ('A'), ('b'), ('B')) tmp(col)
ORDER BY tmp.col COLLATE Latin1_General_BIN2;

यह दिखाता है:

Windows-CaseSensitive
-----------------
a
A
b
B

Windows-Binary
-----------------
A
B
a
b

उदाहरण 3 (यदि कथन):

IF ('A' = 'a') SELECT 1 AS [DatabaseDefault-CaseInsensitive?];
-- if the DB is not case-sensitive or binary, returns 1

IF ('A' = 'a' COLLATE Latin1_General_BIN2) SELECT 2 AS [Windows-Binary];

यह दिखाता है:

DatabaseDefault-CaseInsensitive?
--------------------------------
1

{nothing}

उदाहरण 4 (फंक्शन इनपुट पैरामीटर के साथ सहयोगी):

SELECT  UNICODE(N'🂡') AS [UCS-2],
        UNICODE(N'🂡' COLLATE Latin1_General_100_CI_AS_SC) AS [UTF-16];
-- This character is a Unicode supplemental character and is not part of the
-- default UCS-2 encoding. In order for built-in functions to handle these
-- characters correctly, either the DB default collation needs to end in
-- "_SC" (available as of SQL Server 2012), or use as shown here.
-- See the character in more detail here: http://unicode-table.com/en/1F0A1/

यह दिखाता है:

UCS-2    UTF-16
------   -------
55356    127137

55,356 का यूसीएस -2 मूल्य आंशिक रूप से सही है कि यह "सरोगेट पेयर" में दो मूल्यों में से पहला है। लेकिन जब तक स्पष्ट रूप से _SCटकराव नहीं दिया जाता है, तब तक UNICODE()फ़ंक्शन केवल प्रत्येक चरित्र को एक डबल-बाइट मान के रूप में देख सकता है और यह नहीं जानता कि डबल डबल-बाइट सरोगेट जोड़ी को ठीक से कैसे संभालना है।

अपडेट करें

उपरोक्त सभी उदाहरणों के साथ भी, केस सेंसिटिव तुलनाओं का एक पहलू जिसे आमतौर पर अनदेखा किया जाता है, और बाइनरी तुलनाओं / टकरावों द्वारा नकार दिया जाता है, सामान्यीकरण (रचना और अपघटन) है जो यूनिकोड का हिस्सा है।

उदाहरण 5 (जब एक बाइनरी तुलना नहीं है केस-संवेदी):

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

SELECT 'Equal' AS [Binary],
       NCHAR(0x00FC) AS [ü],
       N'u' + NCHAR(0x0308) AS [u + combining diaeresis]
WHERE  NCHAR(0x00FC) COLLATE Latin1_General_100_BIN2
    =  N'u' + NCHAR(0x0308) COLLATE Latin1_General_100_BIN2
-- No result as they are a different number of code points,
-- as well as being different code points.

SELECT 'Equal' AS [Case-Sensitive],
       NCHAR(0x00FC) AS [ü],
       N'u' + NCHAR(0x0308) AS [u + combining diaeresis]
WHERE  NCHAR(0x00FC) COLLATE Latin1_General_100_CS_AS -- ü
    =  N'u' + NCHAR(0x0308) COLLATE Latin1_General_100_CS_AS -- u + combining diaeresis
-- Result set returned, even being a different number of code points AND Accent Sensitive,
-- due to normalization

यह दिखाता है:

Binary            ü     u + combining diaeresis
-------          ---   -------------------------
{nothing}

Case-Sensitive    ü     u + combining diaeresis
---------------  ---   -------------------------
Equal             ü     ü

सच्ची केस-संवेदी तुलनाएँ व्यापक चरित्रों को उनके गैर-व्यापक समकक्षों के बराबर करने की अनुमति देती हैं।

IF (N'ｓｏｆｉａ' = N'sofia' COLLATE Latin1_General_100_BIN2)
  SELECT 'Values are the same' AS [Binary]
ELSE
  SELECT 'Values are different' AS [Binary];


IF (N'ｓｏｆｉａ' = N'sofia' COLLATE Latin1_General_100_CS_AS)
  SELECT 'Values are the same' AS [Case-Sensitive]
ELSE
  SELECT 'Values are different' AS [Case-Sensitive];

यह दिखाता है:

Binary
---------------
Values are different


Case-Sensitive
---------------
Values are the same

Ergo:

BINARY ( _BINऔर _BIN2) कोलाज केस-सेंसिटिव नहीं हैं !

— सोलोमन रटज़की
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.