Typy danych znakowych

Typy danych znakowych dzielą się na jednobajtowe (CHAR, VARCHAR) i Unicode (NCHAR, NVARCHAR).

Typy danych znakowych – czym są i do czego służą

Typy danych znakowych służą do przechowywania informacji zapisanych jako znaki, czyli między innymi liter, cyfr, spacji, znaków interpunkcyjnych i symboli. W bazach danych stosuje się je wszędzie tam, gdzie wartość nie ma być traktowana wyłącznie jako liczba używana w obliczeniach. Nazwa użytkownika, kod pocztowy, numer dokumentu, adres poczty elektronicznej, opis produktu albo treść komentarza mogą wyglądać jak ciągi cyfr i liter, ale ich podstawowym znaczeniem pozostaje tekst.

Wybór typu znakowego wpływa na sposób zapisu wartości, zajmowane miejsce, dopuszczalną długość oraz zachowanie podczas porównywania i sortowania. Ma to znaczenie zarówno przy projektowaniu tabel, jak i podczas późniejszego odczytywania danych przez aplikacje. Zbyt krótki typ może doprowadzić do obcięcia wartości albo błędu zapisu, natomiast zbyt szeroki typ może utrudniać kontrolę poprawności danych i zwiększać wymagania dotyczące przechowywania.

Podstawowy podział obejmuje typy jednobajtowe, używane zwykle dla ograniczonego zestawu znaków, oraz typy Unicode, przeznaczone do przechowywania tekstu z wielu systemów pisma. W praktyce spotyka się między innymi CHAR, VARCHAR, NCHAR i NVARCHAR. Konkretne zasady mogą nieznacznie różnić się w zależności od używanego systemu bazodanowego, dlatego dokumentacja danego rozwiązania powinna być traktowana jako punkt odniesienia.

Typy danych znakowych – długość stała i zmienna

Typ CHAR przeznaczony jest do wartości o stałej długości. Jeżeli dla kolumny określono długość obejmującą określoną liczbę znaków, krótsza wartość może zostać uzupełniona spacjami zgodnie z zasadami danego systemu. Takie zachowanie bywa użyteczne przy danych rzeczywiście jednorodnych, na przykład przy kodach o zawsze takiej samej długości. Nie powinno się jednak wybierać CHAR tylko dlatego, że tekst jest krótki. Gdy długość wartości często się zmienia, stały rozmiar może być mniej praktyczny.

Typ VARCHAR służy do przechowywania tekstu o długości zmiennej. Zajmowane miejsce jest powiązane z rzeczywistą długością wartości, choć system może dodatkowo przechowywać informacje potrzebne do obsługi długości. VARCHAR dobrze sprawdza się przy nazwach, opisach, identyfikatorach i innych polach, których długość nie jest jednakowa. Przy projektowaniu kolumny należy ustalić rozsądny limit, wynikający z charakteru danych, a nie pozostawiać go bez uzasadnienia.

Odpowiednikiem CHAR dla tekstu Unicode jest NCHAR, natomiast NVARCHAR pozwala przechowywać tekst Unicode o długości zmiennej. Unicode jest istotny w sytuacji, gdy dane mogą zawierać znaki pochodzące z różnych alfabetów, znaki diakrytyczne, symbole matematyczne lub inne elementy niewchodzące do ograniczonego zestawu znaków. Pozwala to uniknąć sytuacji, w której poprawnie wprowadzony tekst zostaje zastąpiony znakami zastępczymi albo ulega zniekształceniu podczas zapisu.

Porównując typy stałej i zmiennej długości, należy uwzględnić nie tylko rozmiar wartości, lecz także sposób jej używania. Tekst o podobnej długości w każdym rekordzie może uzasadniać wybór typu stałej długości, lecz nieregularne opisy zwykle lepiej pasują do typu zmiennego. Decyzja powinna wynikać z modelu danych, przewidywanej zawartości i wymagań aplikacji.

Typy danych znakowych – kodowanie, sortowanie i porównywanie

Samo użycie typu Unicode nie rozwiązuje wszystkich problemów związanych z tekstem. Znaczenie ma również kodowanie oraz reguły porównywania znaków, często określane jako ustawienia sortowania. To one wpływają na kolejność wyników, rozpoznawanie wielkości liter, traktowanie znaków diakrytycznych i porównywanie tekstów uznawanych za podobne. Dwa ciągi mogą wyglądać podobnie, ale zostać ocenione jako różne, jeżeli zastosowano odmienne reguły.

Przy polskich danych trzeba zwrócić uwagę na litery takie jak ą, ć, ę, ł, ń, ó, ś, ź i ż. Jeżeli kolumna, połączenie między tabelami lub aplikacja używa niezgodnych ustawień, mogą pojawić się problemy z wyszukiwaniem i sortowaniem. Niekiedy rekord istnieje w bazie, ale wyszukiwanie wpisane przez użytkownika nie zwraca oczekiwanego wyniku, ponieważ tekst został zapisany w innym kodowaniu albo porównanie odbywa się według innych zasad.

Ważna jest też różnica między liczbą znaków a liczbą bajtów. W przypadku części kodowań jeden znak może zajmować więcej niż jeden bajt. Ograniczenie długości należy zatem interpretować zgodnie z dokumentacją konkretnego typu i systemu. Ma to znaczenie przy importowaniu danych, tworzeniu indeksów oraz przesyłaniu wartości pomiędzy bazą a aplikacją.

Tekstowe pola identyfikacyjne nie powinny być automatycznie zamieniane na typ liczbowy. Numer może zawierać zera na początku, myślniki albo litery, a jego wartość matematyczna nie musi mieć żadnego znaczenia. Kod „00127” po potraktowaniu jako liczba może zostać zapisany jako „127”, co oznacza utratę informacji. Dla takich danych właściwszy jest typ znakowy, nawet jeśli większość wpisów składa się z cyfr.

Typy danych znakowych – typowe problemy w praktyce

Jednym z częstych problemów jest zapis tekstu w kolumnie o zbyt małej długości. Skutkiem może być odrzucenie rekordu, obcięcie końca wartości albo błąd ujawniający się dopiero przy konkretnym wpisie. Ryzyko rośnie, gdy początkowo przyjęty limit nie uwzględnia przyszłych zmian, dłuższych nazw lub danych pochodzących z zewnętrznych formularzy.

Innym problemem są niepotrzebne spacje. Mogą pojawić się przy ręcznej edycji, imporcie plików lub użyciu typu o stałej długości. Spacje na początku albo końcu wartości utrudniają porównania, walidację oraz usuwanie duplikatów. Przed zapisaniem danych można stosować oczyszczanie tekstu, ale nie należy usuwać spacji bezrefleksyjnie, ponieważ w niektórych treściach mogą one mieć znaczenie.

Problemy mogą wynikać także z niezgodności między bazą a aplikacją. Program może wysyłać tekst w innym kodowaniu, niewłaściwie określać długość parametru albo pomijać informację, że wartość zawiera znaki Unicode. W efekcie pojawiają się krzaczki, znaki zapytania lub odmienne wyniki wyszukiwania. Diagnostyka powinna obejmować strukturę kolumny, sposób połączenia, parametry zapytań oraz rzeczywisty zapis w bazie.

Do błędów należy również porównywanie tekstu i liczb bez wyraźnego ustalenia reguł. Wartość „10” może być umieszczona przed „2” przy sortowaniu tekstowym, ponieważ porównanie rozpoczyna się od pierwszego znaku. Przy sortowaniu liczbowym kolejność będzie inna. Jeżeli kolumna przechowuje kody lub identyfikatory, kolejność alfabetyczna może być prawidłowa, ale dla wielkości, kwot i wyników pomiarów należy użyć odpowiednich typów liczbowych.

Typy danych znakowych – praktyczne wskazówki wyboru

Przed utworzeniem kolumny warto opisać znaczenie danych, przewidywaną długość oraz dozwolone znaki. Następnie można zdecydować, czy potrzebny jest tekst Unicode, czy wystarczy ograniczony zestaw znaków. Dla zmiennej długości zwykle rozważa się VARCHAR albo NVARCHAR, a dla ściśle określonego formatu CHAR albo NCHAR. Długość powinna wynikać z reguł biznesowych i realnych przykładów, nie tylko z wygody podczas tworzenia tabeli.

• dla krótkiego kodu o stałym formacie można rozważyć CHAR lub NCHAR;
• dla nazwy lub opisu o zmiennej długości zwykle właściwszy będzie VARCHAR lub NVARCHAR;
• dla tekstu wielojęzycznego należy sprawdzić obsługę Unicode na każdym etapie przepływu danych;
• dla numerów zachowujących zera początkowe należy użyć typu znakowego zamiast liczbowego;
• dla danych wprowadzanych przez użytkownika warto przewidzieć walidację długości, znaków i pustych wartości;
• dla pól wyszukiwanych i sortowanych należy ustalić zgodne reguły porównywania.

Warto również testować wartości graniczne: pusty tekst, tekst o maksymalnej długości, polskie znaki, symbole, wiele spacji oraz znaki pochodzące z innych alfabetów. Test powinien obejmować zapis, odczyt, sortowanie, filtrowanie i eksport. Takie sprawdzenie pozwala wykryć niezgodność wcześniej, zanim problem obejmie większy zbiór rekordów.

Typy danych znakowych – kiedy zgłosić się do serwisu

Wsparcie techniczne może być potrzebne, gdy tekst po zapisaniu zmienia wygląd, polskie znaki są zastępowane innymi symbolami, wyszukiwanie nie znajduje istniejących wartości albo import kończy się błędem długości. Zgłoszenie jest zasadne także wtedy, gdy po zmianie programu, systemu bazodanowego lub ustawień komputera pojawiają się problemy z kodowaniem. Przed przekazaniem danych warto przygotować przykładowe wartości, opis oczekiwanego rezultatu i informację, w którym miejscu występuje nieprawidłowość.

W Warszawie takie problemy można skonsultować z firmą Warszawskie Pogotowie Komputerowe 24/7, która przyjmuje zgłoszenia dotyczące nieprawidłowego działania sprzętu i oprogramowania. Przydatne będzie wskazanie, czy błąd występuje tylko w jednej aplikacji, czy również w innych programach, a także czy dotyczy wszystkich tekstów, czy wyłącznie znaków narodowych. Uporządkowane informacje ułatwiają rozróżnienie problemu z typem danych od problemu z kodowaniem, konfiguracją programu albo nośnikiem danych.

W przypadku pracy z bazą danych należy zachować ostrożność przed zmianą typu kolumny. Najpierw powinno się wykonać kopię danych, sprawdzić zgodność istniejących wartości z nowym formatem i przetestować operację na kopii. Zmiana CHAR na VARCHAR, VARCHAR na NVARCHAR lub odwrotnie może wpływać na indeksy, zapytania, integracje i sposób wyświetlania treści. Przemyślana diagnoza pozwala dobrać rozwiązanie bez utraty zapisanych informacji.