SQL Server-ის collation-ები, Unicode და nvarchar vs varchar

SQL Server-ზე აპლიკაციების უმეტესობისთვის ადამიანისთვის წასაკითხი ტექსტი შეინახე nvarchar-ში, სტრიქონის ლიტერალები დაწერე როგორც N'...' და ბაზა შექმენი თანამედროვე collation-ით, მაგალითად Latin1_General_100_CI_AS_SC. ეს კომბინაცია ნებისმიერ ენასა და ნებისმიერ emoji-ს სწორად ინახავს, ტექსტს რეგისტრის მიუხედავად ადარებს, როგორც მომხმარებლები ელიან, და ემთხვევა იმას, რასაც ყოველი დრაივერი ნაგულისხმევად აგზავნის. SQL Server 2019-დან ალტერნატივაა varchar UTF-8 collation-ით, რომელიც ძირითადად ინგლისურ ტექსტს ნახევარ ადგილში ინახავს, მაგრამ მეტ სიფრთხილეს მოითხოვს. ყველაფერი, რაც SQL Server-ში ტექსტთან დაკავშირებით ფუჭდება - კითხვის ნიშნები იქ, სადაც აქცენტები უნდა იყოს, Cannot resolve the collation conflict, ინდექსი, რომელიც უცებ იგნორირდება - ამ არჩევანების უნებლიე შერევით მოდის. ეს გზამკვლევი თითოეულ ნაწილს ხსნის, რომ შეგნებულად აირჩიო.

varchar, nvarchar და რას ნიშნავს N#

SQL Server-ს სტრიქონის ტიპების ორი ოჯახი აქვს:

მახე მესამე სვეტშია. varchar(50) არის 50 ბაიტი და არა 50 სიმბოლო, nvarchar(50) კი 50 UTF-16 code unit-ია და ისიც არა 50 სიმბოლო. ყოველდღიური ლათინური ტექსტისთვის განსხვავება არასოდეს ჩანს. emoji-სთვის, რომელსაც ორი UTF-16 code unit სჭირდება, ან ჩინურისთვის, რომელიც UTF-8-ში სიმბოლოზე სამ ბაიტს იკავებს, ჩანს.

UTF-8 collation-ის გარეშე varchar ტექსტს ერთ ძველ code page-ში ინახავს - Windows-1252-ში ლათინური collation-ებისთვის, რომლებსაც სერვერების უმეტესობა იყენებს. ამ code page-ში ადგილია ინგლისურისა და დასავლეთ ევროპული აქცენტების უმეტესობისთვის და მეტი არაფრისთვის. შეინახე მასში პოლონური, ბერძნული, კირილიცა, არაბული ან ნებისმიერი emoji და SQL Server ჩუმად, ჩაწერის მომენტში ჩაანაცვლებს კითხვის ნიშნით ან მსგავსი სიმბოლოთი. მონაცემები დაკარგულია; ვერანაირი შემდგომი კონვერტაცია მათ ვერ დააბრუნებს.

ლიტერალზე N პრეფიქსი იგივე არჩევანია, მუდმივებზე გამოყენებული. 'Zoë' არის varchar ლიტერალი ბაზის code page-ში; N'Zoë' Unicode ლიტერალია. ჩასვი 'Łódź' nvarchar სვეტში და მაინც დაზიანებულ ტექსტს მიიღებ, რადგან ლიტერალი code page-ში კონვერტირდა მანამ, სანამ სვეტამდე მივიდოდა:

CREATE TABLE dbo.Cities (Name nvarchar(100) NOT NULL);INSERT dbo.Cities (Name) VALUES ('Łódź');   -- arrives as 'Lódz' or with '?'INSERT dbo.Cities (Name) VALUES (N'Łódź');  -- arrives intactSELECT Name FROM dbo.Cities;

აპლიკაციის კოდი, რომელიც პარამეტრებს იყენებს, აქ უსაფრთხოა, რადგან დრაივერები სტრიქონებს ნაგულისხმევად Unicode-ად აგზავნიან. N-ს მნიშვნელობა აქვს სკრიპტებში, მიგრაციებში, საწყის მონაცემებში და ყველაფერში, რასაც SSMS-ში აკრეფ. ჩვევად აქციე ყოველი სტრიქონის ლიტერალისთვის, რომელიც nvarchar სვეტისკენ მიდის.

რას წყვეტს collation#

Collation არის წესების ნაკრები, მიმაგრებული სერვერზე, ბაზაზე, სვეტზე ან გამოსახულებაზე. ის სამ რამეს წყვეტს:

1. რომელი სიმბოლოების შენახვა შეუძლია `varchar`-ს - code page ან UTF-8.
2. როგორ ედარება სტრიქონები ერთმანეთს - არის თუ არა 'abc' = 'ABC', არის თუ არა 'resume' = 'résumé'.
3. როგორ ლაგდება სტრიქონები - რა თანმიმდევრობით აბრუნებს ORDER BY და, შესაბამისად, ტექსტურ სვეტზე აგებული ინდექსის თანმიმდევრობა.

Collation-ის სახელები წესებს კოდავს, და როცა მათ კითხვას ისწავლი, არჩევანი გაცილებით მარტივდება:

ამრიგად, Latin1_General_100_CI_AS_SC_UTF8 ნიშნავს: ზოგადი ლათინური წესები, ვერსია 100, რეგისტრისადმი არამგრძნობიარე, აქცენტისადმი მგრძნობიარე, დამატებითი სიმბოლოების მცოდნე, UTF-8 varchar-ში. სერვერისთვის ცნობილი ყველა collation ჩამოთვალე SELECT name, description FROM sys.fn_helpcollations();-ით.

Windows collation-ები და SQL_ collation-ები#

SQL_-ით დაწყებული collation-ები ძველი ოჯახია, შენარჩუნებული 1990-იანი წლების SQL Server-ის ვერსიებთან თავსებადობისთვის. ყველაზე ცნობილია SQL_Latin1_General_CP1_CI_AS, რომელიც ჯერ კიდევ ნაგულისხმევი სერვერის collation-ია ინგლისური (აშშ) Windows-ის ინსტალაციისთვის და ნაგულისხმევია Linux-ზე. დანარჩენი - Latin1_General_100_CI_AS და მისი მსგავსები - Windows collation-ებია.

მთავარი განსხვავება ისაა, როგორ ექცევიან ისინი varchar-ს. Windows collation ერთსა და იმავე ენობრივ წესებს იყენებს varchar-სა და nvarchar-ზე. SQL_ collation კი varchar-ისთვის უფრო ძველ, მარტივ წესებს იყენებს, nvarchar-ისთვის - Windows-ის წესებს, ამიტომ ერთი და იგივე ორი სტრიქონი შეიძლება სხვადასხვაგვარად შედარდეს ან დალაგდეს მათი ტიპის მიხედვით. ის ასევე ცვლის იმას, რა ხდება, როცა nvarchar პარამეტრი varchar სვეტს ხვდება: Windows collation-ით ოპტიმიზატორს ხშირად მაინც შეუძლია ინდექსზე seek, SQL_ collation-ით კი scan-ს აკეთებს. დატვირთულ ცხრილზე ეს განსხვავებაა მილიწამიან და წამიან query-ს შორის, და კოდში ის უხილავია. SQL Server-ის ინდექსები და execution plan-ები აჩვენებს, როგორ გამოიყურება ეს plan-ში.

ახალი ბაზისთვის SQL_ collation-ის არჩევის მიზეზი არ არსებობს. გამოიყენე ვერსია 100-ის Windows collation და დაამატე _SC, რომ სტრიქონის ფუნქციებმა emoji და სხვა დამატებითი სიმბოლოები სწორად დათვალონ:

SELECT LEN(N'😀' COLLATE Latin1_General_100_CI_AS)     AS without_sc,   -- 2       LEN(N'😀' COLLATE Latin1_General_100_CI_AS_SC)  AS with_sc;      -- 1

UTF-8 collation-ები: varchar, რომელიც ყველაფერს ინახავს#

SQL Server 2019-მა დაამატა _UTF8-ით დამთავრებული collation-ები. ასეთით varchar სვეტები UTF-8-ს ინახავენ, ამიტომ ყოველ Unicode სიმბოლოს იტევენ, ჩვეულებრივი ASCII ტექსტი კი სიმბოლოზე ერთ ბაიტს იკავებს იმ ორის ნაცვლად, რასაც nvarchar იყენებს.

აპლიკაციისთვის, რომლის ტექსტიც ძირითადად ინგლისური, პროდუქტის კოდები, URL-ები და JSON-ია, UTF-8 varchar-ს სტრიქონების დაკავებული ადგილის დაახლოებით განახევრება შეუძლია - რაც Express-ზე მნიშვნელოვანია, სადაც ყოველი ბაზა 10 GB-ით არის შეზღუდული. ძირითადად აღმოსავლეთ აზიური ტექსტისთვის ის nvarchar-ზე დიდია და არა პატარა.

ხარჯები ღირს იცოდე, სანამ გადაწყვეტ:

• varchar(n) მაინც ბაიტებს ითვლის, ამიტომ varchar(50) 50 ASCII სიმბოლოს იტევს, მაგრამ მხოლოდ 16 ჩინურს. სვეტების ზომა რეალური მონაცემების ბაიტების სიგრძით შეარჩიე, ან გამოიყენე varchar(max) იქ, სადაც ამას მნიშვნელობა არ აქვს.
• დრაივერები სტრიქონებს ნაგულისხმევად მაინც nvarchar-ად აგზავნიან, ამიტომ პარამეტრთან ყოველი შედარება კონვერტაციას მოიცავს, თუ პარამეტრებს varchar-ად არ გამოაცხადებ. EF Core ამას აკეთებს, როცა property IsUnicode(false)-ით არის მიბმული; ADO.NET-ით დააყენე SqlDbType.VarChar; JDBC დრაივერით - sendStringParametersAsUnicode=false.
• მხოლოდ ზოგიერთი ინსტრუმენტი და ძველი კლიენტის ბიბლიოთეკა გრძნობს თავს მასთან კომფორტულად. გატესტე მთელი სტეკი, რეპორტინგისა და ETL-ის ჩათვლით.

UTF-8 collation საღი არჩევანია ახალი აპლიკაციისთვის, სადაც მონაცემებზე წვდომის ფენას შენ აკონტროლებ და ადგილს მნიშვნელობა აქვს. თუ ეჭვი გაქვს, nvarchar ის არჩევანია, რომელიც ვერ გაგაკვირვებს.

სერვერის, ბაზის, სვეტისა და გამოსახულების collation#

Collation ოთხ დონეზე ყენდება და თითოეული შემდეგისთვის ნაგულისხმევია:

• სერვერი - ინსტალაციისას ირჩევა. ეს სისტემური ბაზების collation-ია, tempdb-ის ჩათვლით. Linux-ზე ის MSSQL_COLLATION-ით ან mssql-conf set-collation-ით ყენდება, და მისი მოგვიანებით შეცვლა სისტემური ბაზების ხელახლა აგებას ნიშნავს.
• ბაზა - ყენდება CREATE DATABASE ... COLLATE-ით, ნაგულისხმევად სერვერისას იღებს. ის ნაგულისხმევია ახალი სვეტებისთვის, ლიტერალებისა და ცვლადებისთვის ამ ბაზაში, და ის განსაზღვრავს ობიექტების სახელებს - ამიტომ რეგისტრისადმი არამგრძნობიარე ბაზაში dbo.Orders და dbo.ORDERS ერთი და იგივე ცხრილია.
• სვეტი - ყენდება CREATE TABLE-ში ან ALTER TABLE ... ALTER COLUMN-ში, ნაგულისხმევად ბაზისას იღებს.
• გამოსახულება - COLLATE ნაწილი მას ერთი შედარების ან დალაგებისთვის აუქმებს.

SELECT SERVERPROPERTY('Collation')                  AS server_collation,       DATABASEPROPERTYEX(DB_NAME(), 'Collation')   AS database_collation;SELECT t.name AS table_name, c.name AS column_name, c.collation_nameFROM sys.columns AS cJOIN sys.tables  AS t ON t.object_id = c.object_idWHERE c.collation_name IS NOT NULLORDER BY t.name, c.column_id;

ჰოსტინგის სერვერზე იღებ სერვერის collation-ს, რომელსაც ვერ შეცვლი. რასაც შენ აკონტროლებ, ბაზაა: sa-ს სახით შეგიძლია ახალი ბაზა შექმნა სასურველი collation-ით. RE:NODE-ზე ბაზა შენთვის იქმნება და sa-ს ნაგულისხმევად ყენდება; მასზე აშენებამდე შეამოწმე მისი collation ზემოთ მოცემული query-ით, და თუ ის არ არის ის, რაც გინდა, შექმენი სხვა CREATE DATABASE [app] COLLATE Latin1_General_100_CI_AS_SC;-ით, სანამ ჯერ კიდევ ცარიელია.

Collation-ის კონფლიქტის შეცდომა#

შეცდომა, რომელსაც ადრე თუ გვიან ყველა ხვდება:

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

სხვადასხვა collation-ის მქონე ორი სტრიქონის შედარება შეუძლებელია, რადგან SQL Server-მა არ იცის, ვისი წესები გამოიყენოს. ყველაზე ხშირი წყარო tempdb-ია. დროებითი ცხრილები tempdb-ში იქმნება, ამიტომ მათი სვეტები სერვერის collation-ს იღებენ და არა შენი ბაზისას. თუ ეს ორი განსხვავდება, დროებითი ცხრილის ნამდვილთან join ვარდება.

-- Fails if the server and database collations differCREATE TABLE #ids (Code varchar(20));-- Works everywhere: take the current database's collationCREATE TABLE #ids (Code varchar(20) COLLATE DATABASE_DEFAULT);

ჩვევად აქციე COLLATE DATABASE_DEFAULT ყოველი დროებითი ცხრილის ყოველ სტრიქონულ სვეტზე და სერვერებს შორის გადატანილი კოდი გატეხვას შეწყვეტს. ცხრილის ცვლადები ბაზის collation-ით იქმნება და პრობლემას თავს არიდებს. ერთჯერადი შედარებისთვის COLLATE გამოსახულების ერთ მხარეს მას აგვარებს, იმ ფასად, რომ კონვერტირებული მხარის ინდექსი seek-ისთვის ვეღარ გამოიყენება.

ბაზის აღდგენა სერვერზე, რომელსაც განსხვავებული collation აქვს, იმავე პრობლემას იწვევს, და ბაზა საკუთარ collation-ს ინარჩუნებს; განსხვავდება მხოლოდ tempdb და სისტემური ბაზები. ეს კიდევ ერთი მიზეზია, რომ გამოიყენო DATABASE_DEFAULT და არა collation-ის სახელი.

რეგისტრის მგრძნობელობა და შედარების სხვა სიურპრიზები#

რამდენიმე ქცევა, რომელიც წესების მიხედვით სწორია და პრაქტიკაში მოულოდნელი:

• რეგისტრისადმი არამგრძნობიარე უნიკალურობა. CI collation-ით Email-ზე უნიკალური ინდექსი უარყოფს Bob@example.com-ს, როცა bob@example.com უკვე არსებობს. ჩვეულებრივ ეს ის არის, რაც გინდა; ზოგჯერ, რეგისტრისადმი მგრძნობიარე იდენტიფიკატორებისთვის, როგორიცაა token-ები, ასე არ არის, და იმ სვეტს CS ან BIN2 collation სჭირდება.
• ბოლოში მდგომი ჰარები შედარებისას იგნორირდება. 'abc' = 'abc ' ჭეშმარიტია, SQL სტანდარტის padding-ის წესების მიხედვით. LEN ასევე უგულებელყოფს ბოლოში მდგომ ჰარებს; DATALENGTH - არა. LIKE გამონაკლისია და შაბლონს არ ავსებს.
• აქცენტის მგრძნობელობა რეგისტრისგან დამოუკიდებელია. CI_AS ამბობს, რომ 'resume' <> 'résumé'. თუ მომხმარებლები სახელებს აქცენტების აკრეფის გარეშე ეძებენ, AI collation იმ სვეტზე, ან ცალკე ნორმალიზებული საძიებო სვეტი, მათ იმ ქცევას აძლევს, რასაც ელიან.
• `COLLATE` `WHERE` ნაწილში ინდექსის seek-ებს თიშავს იმ სვეტზე. რეგისტრისადმი არამგრძნობიარე სვეტში რეგისტრისადმი მგრძნობიარე ძებნისთვის scan-ის გარეშე ჯერ ჩვეულებრივად შეადარე (რასაც seek შეუძლია), შემდეგ კი დაამატე რეგისტრისადმი მგრძნობიარე შემოწმება:

SELECT UserIdFROM dbo.UsersWHERE UserName = @name  AND UserName = @name COLLATE Latin1_General_100_CS_AS;

პირველი პირობა seek-ით მიდის იმ რამდენიმე row-მდე, რომლებიც რეგისტრის უგულებელყოფით ემთხვევა; მეორე კი ამ რამდენიმეს ზუსტად ფილტრავს.

ენობრივი და ბინარული collation-ები#

Latin1_General კომპრომისია, რომელიც გონივრულად ალაგებს ინგლისურისა და დასავლეთ ევროპული ენების უმეტესობისთვის. ზოგიერთ ენას აქვს წესები, რომლებსაც ის არ მისდევს, და თუ შენი მომხმარებლები დალაგებულ სიებს ამ ენებზე კითხულობენ, ამას შეამჩნევენ:

• თურქულს აქვს წერტილიანი და უწერტილო i, ამიტომ i-ის დიდი ასოა İ, I-ის პატარა კი ı. Turkish_100_CI_AS-ით UPPER(N'i') აბრუნებს İ-ს, და 'FILE'-ის 'file'-თან რეგისტრისადმი არამგრძნობიარე შედარება მცდარია. Latin1_General-ით თურქი მომხმარებლები თავიანთ სახელებს არასწორად დალაგებულს და არასწორი რეგისტრით ხედავენ.
• დანიური და ნორვეგიული æ, ø და å-ს z-ის შემდეგ ალაგებს და ძველ მართლწერას aa თვლის å-დ. Danish_Norwegian_100_CI_AS ამას აკეთებს; Latin1_General კი Ålesund-ს Aalborg-ის გვერდით, დასაწყისში აყენებს.
• პოლონური, ჩეხური და სხვა ცენტრალური ევროპული ენები აქცენტიან ასოებს ცალკე ასოებად ალაგებს მათი საბაზისო ასოს შემდეგ. თითოეულს საკუთარი collation-ების ოჯახი აქვს.
• გერმანულს ორი კონვენცია აქვს. ნაგულისხმევი ä-ს a-ს ვარიანტად თვლის; German_PhoneBook_100_CI_AS მას ae-დ ალაგებს, როგორც ტელეფონის ცნობარები აკეთებდნენ.

მთელი ბაზისთვის ერთი ენის არჩევა არ გიწევს. სვეტის დონის collation, ან ORDER BY Name COLLATE Danish_Norwegian_100_CI_AS ერთ query-ზე, წესებს იქ იყენებს, სადაც ეს მნიშვნელოვანია. თუმცა ინდექსი თავისი სვეტის collation-ით არის დალაგებული, ამიტომ query, რომელიც სხვა collation-ით ალაგებს, ინდექსის თანმიმდევრობას ვერ გამოიყენებს და თავად უწევს დალაგება.

მეორე ბოლოში BIN2-ით დამთავრებული ბინარული collation-ებია. ისინი ნედლ code point-ებს ადარებენ: არანაირი ენობრივი წესი, რეგისტრისადმი მგრძნობიარე, აქცენტისადმი მგრძნობიარე და ყველაზე იაფი შედარებები, რისი გაკეთებაც SQL Server-ს შეუძლია. დიდი ასოები ყველა პატარაზე ადრე ლაგდება, ამიტომ 'Zebra' 'apple'-ზე წინ მოდის. ეს მათ არასწორს ხდის ყველაფრისთვის, რასაც ადამიანი დალაგებული თანმიმდევრობით კითხულობს, და სწორს მანქანური იდენტიფიკატორებისთვის - API გასაღებები, hash-ები, token-ები, რეგისტრისადმი მგრძნობიარე კოდები - სადაც ზუსტი დამთხვევაა მთავარი და სიჩქარე გეხმარება. BIN2 collation ასეთ სვეტზე ასევე უშლის ხელს რეგისტრისადმი არამგრძნობიარე ნაგულისხმევს, ორი განსხვავებული token დუბლიკატად ჩათვალოს.

Collation-ის შეცვლა მოგვიანებით#

ბაზის collation-ის შეცვლა შესაძლებელია, მაგრამ იმაზე ნაკლებს აკეთებს, ვიდრე ხალხს იმედი აქვს:

ALTER DATABASE [app] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;ALTER DATABASE [app] COLLATE Latin1_General_100_CI_AS_SC;ALTER DATABASE [app] SET MULTI_USER;

ეს ცვლის ნაგულისხმევს ახალი სვეტებისთვის და ობიექტების სახელების წესებს. ის არ ეხება არსებულ სვეტებს, რომლებიც ძველ collation-ს ინარჩუნებენ, და ვარდება, თუ schema-bound ობიექტები, როგორიცაა ინდექსირებული view-ები ან გამოთვლადი სვეტები, მიმდინარე collation-ზეა დამოკიდებული. ყოველი არსებული სვეტი ცალ-ცალკე უნდა შეიცვალოს, რაც მოითხოვს ყოველი ინდექსის, შეზღუდვისა და სტატისტიკის წაშლასა და ხელახლა შექმნას, რომელიც მას იყენებს:

ALTER TABLE dbo.CustomersALTER COLUMN Name nvarchar(200) COLLATE Latin1_General_100_CI_AS_SC NOT NULL;

გაიმეორე სვეტის nullability, თორემ ALTER COLUMN მას nullable-ს გახდის. ნებისმიერი ზომის ბაზაზე უფრო სუფთა გზა ხშირად ისაა, რომ შექმნა ახალი ბაზა სწორი collation-ით, იქ შექმნა სქემა და მონაცემები გადაიტანო bcp-ით ან INSERT ... SELECT-ით. ბაზის მიგრაცია SQL Server ჰოსტინგზე მექანიკას მოიცავს, MySQL utf8mb4 და collation-ები კი იგივე ამბავია MySQL-ისთვის მოთხრობილი, თუ იქიდან მოდიხარ.

FAQ#

nvarchar გამოვიყენო თუ varchar ახალი აპლიკაციისთვის?

nvarchar ყველაფრისთვის, რასაც ადამიანები კრეფენ - სახელები, მისამართები, შეტყობინებები - თუ ადგილი შეზღუდული არ არის და ყოველ პარამეტრის ტიპს შენ არ აკონტროლებ; ასეთ შემთხვევაში varchar UTF-8 collation-ით კარგი ვარიანტია. ჩვეულებრივი varchar არა-UTF-8 collation-ით უსაფრთხოა მხოლოდ კოდებისა და იდენტიფიკატორებისთვის, რომლებზეც იცი, რომ ASCII-ა.

რატომ იქცევა ჩემი აქცენტიანი სიმბოლოები კითხვის ნიშნებად?

ტექსტმა გაიარა code page, რომელსაც მათი წარმოდგენა არ შეუძლია: varchar სვეტი UTF-8 collation-ის გარეშე, ან სტრიქონის ლიტერალი, დაწერილი N პრეფიქსის გარეშე. შეამოწმე სვეტის ტიპი და ლიტერალებს დაუმატე N. კითხვის ნიშნებით უკვე შენახული ტექსტის აღდგენა შეუძლებელია.

შემიძლია SQL Server-ში emoji-ს შენახვა?

დიახ, nvarchar-ში ნებისმიერი collation-ით, ან varchar-ში UTF-8 collation-ით. გამოიყენე _SC collation, თუ გინდა, რომ LEN-მა, SUBSTRING-მა და მსგავსმა ფუნქციებმა ყოველი emoji ერთ სიმბოლოდ ჩათვალონ და არა ორად.

რომელი collation უნდა გამოიყენოს ახალმა ბაზამ?

Latin1_General_100_CI_AS_SC ინგლისური ან დასავლეთ ევროპული აპლიკაციისთვის, რომელიც nvarchar-ს იყენებს, ან Latin1_General_100_CI_AS_SC_UTF8, თუ UTF-8 varchar-ის გამოყენებას გეგმავ. გამოიყენე ენობრივი collation, როცა დალაგება ერთი ენის წესებს უნდა მისდევდეს, მაგალითად პოლონურის ან თურქულის.

არის SQL Server რეგისტრისადმი მგრძნობიარე?

ნაგულისხმევად არა. მონაცემთა შედარებები და ობიექტების სახელები collation-ს მისდევს, ნაგულისხმევი collation-ები კი რეგისტრისადმი არამგრძნობიარეა. ბაზაზე რეგისტრისადმი მგრძნობიარე collation ცხრილებისა და სვეტების სახელებსაც მგრძნობიარეს ხდის, რაც აპლიკაციის კოდს აკვირვებს, ამიტომ ის ნაცვლად კონკრეტულ სვეტებზე გამოიყენე.