Kolacja kolumny NVARCHAR wpływa na sortowanie i porównywanie, ale nie na zestaw znaków — ten obejmuje pełny Unicode.
NVARCHAR przechowuje dane, a kolacja określa reguły ich oceny
W Microsoft SQL Server typ nvarchar służy do przechowywania tekstu w kodowaniu Unicode. Litera „n” w nazwie typu wskazuje na obsługę znaków Unicode, dlatego zawartość kolumny nie jest ograniczona do alfabetu łacińskiego. W jednej wartości mogą znajdować się między innymi litery z różnych alfabetów, znaki diakrytyczne, symbole matematyczne oraz emoji. Kolacja nie wybiera dostępnego zestawu znaków i nie zamienia kolumny nvarchar w inny typ danych. Jej zadaniem jest określenie zasad porównywania, sortowania i dopasowywania tekstu.
W SQL Server nvarchar(n) używa liczby n jako maksymalnej liczby par bajtów, a nie jako liczby bajtów przeznaczonych na każdy znak. Typowa wartość n może mieć zakres od 1 do 4000, natomiast nvarchar(max) pozwala przechowywać znacznie większe wartości, do limitu wynikającego z architektury SQL Server. Dane są przechowywane jako sekwencje jednostek UTF-16. W przypadku znaków spoza podstawowej płaszczyzny wielojęzycznej znaczenie ma również to, czy użyta kolacja obsługuje znaki dodatkowe, czyli tak zwane supplementary characters.
Jak kolacja wpływa na równość, sortowanie i wyszukiwanie
Kolacja może określać wrażliwość porównania na wielkość liter, akcenty, kana w języku japońskim oraz szerokość znaków. Przykładowo kolacja niewrażliwa na wielkość liter może traktować „abc” i „ABC” jako wartości równe podczas porównania, choć zapisane ciągi nadal pozostają różnymi sekwencjami znaków. Kolacja wrażliwa na akcenty może odróżniać „a” od „ą”, a kolacja niewrażliwa na akcenty może uznać je za równoważne w określonych operacjach porównawczych. Właściwości te są oznaczane w nazwach kolacji skrótami, takimi jak CI dla case-insensitive i CS dla case-sensitive oraz AI i AS dla odpowiednio accent-insensitive i accent-sensitive.
Reguły kolacji są używane między innymi przez operatory równości i nierówności, predykat LIKE, sortowanie ORDER BY, grupowanie oraz niektóre operacje agregujące. Mają również znaczenie dla unikatowych indeksów i ograniczeń unikatowości. Jeżeli kolacja uznaje dwa różnie zapisane ciągi za równoważne, indeks unikatowy może zablokować zapis drugiej wartości. Z tego powodu wybór kolacji wpływa nie tylko na wygląd wyników zapytania, ale także na to, jakie rekordy SQL Server uzna za duplikaty.
Poziomy ustawienia kolacji w SQL Server
Kolacja może być określona na poziomie instancji SQL Server, bazy danych, kolumny albo pojedynczego wyrażenia. Ustawienie kolacji bazy jest domyślnie dziedziczone przez nowe kolumny tekstowe, ale definicja kolumny może wskazywać inną kolację za pomocą klauzuli COLLATE. Przykładowa definicja może wyglądać następująco: Nazwa nvarchar(200) COLLATE Polish_100_CI_AS. Oznacza to, że kolumna ma typ Unicode, limit długości określony przez 200 par bajtów i własne reguły porównywania, niezależne od domyślnej kolacji bazy.
Kolację można także zmienić tylko na czas działania zapytania, na przykład przez wyrażenie WHERE Nazwa COLLATE Polish_100_CI_AS = @Nazwa. Takie użycie może rozwiązać konkretny problem z porównaniem, ale zastosowane bez potrzeby utrudnia analizę zapytania i może wpłynąć na możliwość wykorzystania indeksu. Szczególnej uwagi wymagają porównania kolumn pochodzących z różnych baz lub tabel. Gdy SQL Server napotka niezgodne kolacje, może zgłosić błąd konfliktu kolacji. Wtedy trzeba świadomie ustalić, które reguły mają obowiązywać, zamiast przypadkowo wymuszać konwersję.
Weryfikacja kolumny NVARCHAR i dobór właściwej kolacji
Podczas sprawdzania problemu z sortowaniem lub wyszukiwaniem należy najpierw odczytać definicję kolumny, jej typ, długość i kolację. Pomocne są widoki katalogowe, takie jak sys.columns, sys.types i sys.tables, a także polecenie sp_help użyte dla konkretnej tabeli. Warto osobno porównać wynik sortowania, operatora równości oraz LIKE, ponieważ pozornie podobne zapytania mogą ujawniać różne skutki reguł kolacji. Należy również sprawdzić kolację parametrów, zmiennych i wyrażeń pośrednich, zwłaszcza gdy zapytanie łączy dane z wielu źródeł.
Nie należy traktować zmiany kolacji jako sposobu naprawy uszkodzonego kodowania. Jeżeli znak został utracony przed zapisaniem do SQL Server albo aplikacja wysłała nieprawidłowo zakodowane dane, sama klauzula COLLATE ich nie odtworzy. Przy danych wymagających jednoznacznego porządku technicznego można rozważyć kolacje binarne, w tym warianty BIN2, ale ich działanie różni się od językowych reguł sortowania. Trzeba też pamiętać, że nvarchar i kolacje Unicode to nie to samo co obsługa UTF-8 dla typu varchar. UTF-8 w SQL Server dotyczy kolacji oznaczonych sufiksem _UTF8 i jest mechanizmem używanym z typami znakowymi innymi niż nvarchar.
