NVARCHAR a VARCHAR

NVARCHAR przechowuje tekst w Unicode i zajmuje dwa bajty na znak, VARCHAR korzysta z jednobajtowej strony kodowej kolacji.

Unicode i strona kodowa w SQL Server

NVARCHAR i VARCHAR to typy danych tekstowych stosowane w Microsoft SQL Server, ale przeznaczone do innych modeli zapisu znaków. NVARCHAR przechowuje dane w formacie Unicode, dlatego może reprezentować znaki pochodzące z wielu alfabetów w jednej kolumnie: między innymi polskiego, greckiego, cyrylicy, arabskiego, chińskiego czy japońskiego. VARCHAR przechowuje tekst zgodnie z kodowaniem wynikającym z kolacji i strony kodowej przypisanej do danych. Oznacza to, że zakres poprawnie zapisywanych znaków zależy od konkretnej konfiguracji SQL Server, bazy danych, kolumny albo wyrażenia.

W SQL Server typ NVARCHAR wykorzystuje kodowanie Unicode oparte na parach bajtów dla podstawowego zakresu znaków, natomiast znaki spoza podstawowej płaszczyzny Unicode mogą wymagać dwóch jednostek kodowych. Dlatego uproszczenie mówiące o dwóch bajtach na każdy znak nie jest ścisłe dla całego Unicode. W przypadku VARCHAR liczba bajtów i możliwość zapisania danego symbolu wynikają z użytej strony kodowej. Tekst zawierający wyłącznie znaki obsługiwane przez daną stronę kodową może działać poprawnie, ale pojedynczy znak spoza tego zakresu może zostać zastąpiony znakiem zapytania albo utracony podczas konwersji.

Rozmiar kolumny a rzeczywista długość tekstu

W deklaracji kolumny można użyć na przykład NVARCHAR(100) albo VARCHAR(100). Liczba w nawiasie określa maksymalną długość wartości, lecz interpretacja tej długości zależy od typu i sposobu liczenia jednostek. Dla VARCHAR limit odnosi się do bajtów, a dla NVARCHAR do liczby jednostek kodowych UTF-16. W praktyce tekst złożony ze znaków podstawowych zwykle zajmuje jedną jednostkę kodową na znak, natomiast niektóre symbole wymagają dwóch jednostek. Z tego powodu limit nie powinien być dobierany wyłącznie na podstawie liczby widocznych znaków.

Typ NVARCHAR zwykle potrzebuje więcej miejsca dla tekstu złożonego ze znaków alfabetu łacińskiego, ponieważ każda jednostka kodowa zajmuje dwa bajty. VARCHAR może być bardziej oszczędny, gdy dane są ograniczone do znaków dostępnych w odpowiedniej stronie kodowej. Oszczędność miejsca nie uzasadnia jednak automatycznego używania VARCHAR dla wszystkich pól tekstowych. Jeżeli aplikacja ma przyjmować dane wielojęzyczne, nazwy własne, symbole walut, znaki matematyczne lub emoji, wybór VARCHAR może prowadzić do nieodwracalnej utraty informacji.

Literał tekstowy, konwersja i porównywanie wartości

W SQL Server znaczenie ma nie tylko typ kolumny, lecz także typ wyrażenia przekazywanego do zapisu lub porównania. Zwykły literał tekstowy zapisany jako 'Łódź' jest literałem typu VARCHAR. Literał Unicode powinien być poprzedzony literą N, na przykład N'Łódź'. Brak prefiksu N może spowodować, że tekst zostanie najpierw zinterpretowany w kodowaniu VARCHAR, zanim trafi do kolumny NVARCHAR. Sam fakt, że kolumna docelowa obsługuje Unicode, nie naprawia danych utraconych podczas wcześniejszej konwersji.

Konwersje pomiędzy VARCHAR i NVARCHAR mogą zachodzić jawnie przez CAST lub CONVERT, ale również niejawnie podczas porównywania kolumn, parametrów i literałów. SQL Server stosuje wtedy reguły pierwszeństwa typów oraz kolacji. Taka konwersja może wpływać na wynik porównania, wykorzystanie indeksu i czas wykonania zapytania. Należy również rozróżnić kolację od typu danych: kolacja określa między innymi reguły sortowania, porównywania oraz czułość na wielkość liter, lecz nie zamienia VARCHAR w pełny typ Unicode. Przy analizie problemu trzeba sprawdzić definicję kolumny, typ parametrów procedury lub zapytania, użyte literały oraz kolację.

Problemy są szczególnie widoczne podczas migracji danych. Zapis do VARCHAR znaków nieobsługiwanych przez wybraną stronę kodową może zakończyć się zastąpieniem ich znakiem zapytania. Późniejsza zmiana kolumny na NVARCHAR nie odtworzy oryginalnych znaków, jeżeli zostały już utracone. Bezpieczna weryfikacja obejmuje porównanie danych źródłowych i docelowych, sprawdzenie typów parametrów oraz wykonanie testów z reprezentatywnym zestawem znaków, a nie tylko z tekstem zawierającym polskie litery.

Dobór typu podczas diagnostyki bazy i aplikacji

Przy diagnozowaniu nieprawidłowego zapisu tekstu należy ustalić pełny przepływ wartości: od pola formularza, przez parametr sterownika lub procedury, do kolumny i późniejszego odczytu. Jeżeli aplikacja wysyła parametr jako VARCHAR, a kolumna ma typ NVARCHAR, problem może wystąpić jeszcze przed wykonaniem instrukcji INSERT lub UPDATE. Warto sprawdzić także długość parametrów, ponieważ zbyt krótki parametr może obciąć wartość niezależnie od tego, czy docelowa kolumna ma typ NVARCHAR, czy VARCHAR.

W typowej bazie SQL Server NVARCHAR jest właściwym wyborem dla danych, które nie mają ograniczonego alfabetu i mogą być wprowadzane przez różnych użytkowników lub systemy. VARCHAR może być uzasadniony dla kontrolowanych danych o określonym zestawie znaków, lecz decyzja powinna wynikać z wymagań aplikacji, kolacji, rozmiaru tabeli i indeksów. Podczas przeglądu laptopa lub komputera PC można sprawdzić konfigurację używanego programu, sterownika oraz lokalnego środowiska, gdy objaw pojawia się tylko na jednym stanowisku. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, a w przypadku problemów z aplikacją analizuje również zależności między środowiskiem komputera a działaniem oprogramowania.

Praktyczny test powinien obejmować zapis i odczyt tekstu zawierającego znaki z kilku alfabetów oraz symbol wymagający więcej niż jednej jednostki kodowej. Następnie należy porównać wartość przed zapisem z wartością odczytaną z bazy i sprawdzić komunikaty o konwersji lub obcięciu danych. Taka kontrola pozwala odróżnić problem typu kolumny od błędu w parametrze, kolacji, sterowniku albo kodzie aplikacji. Nie należy usuwać danych ani zmieniać typu kolumny bez wcześniejszego wykonania kopii i sprawdzenia wpływu konwersji na istniejące rekordy, indeksy oraz ograniczenia tabeli.