Poprawny wybór to CHAR(11), ponieważ numer PESEL nie jest liczbą w sensie matematycznym, tylko identyfikatorem tekstowym złożonym z 11 znaków. W praktyce nigdy nie wykonujemy na PESEL‑u operacji arytmetycznych (dodawanie, odejmowanie, mnożenie), więc trzymanie go w typie numerycznym nie ma sensu i zwykle tylko komplikuje życie. Z punktu widzenia projektowania baz danych przyjmuje się dobrą praktykę: wszystkie identyfikatory, które mają stałą długość i mogą zaczynać się od zera, zapisujemy w typie znakowym o stałej długości, czyli właśnie CHAR(n). Dzięki CHAR(11) mamy gwarancję, że w każdej komórce kolumny PESEL będzie dokładnie 11 znaków. Silnik bazy danych może to łatwo sprawdzić, co pomaga w walidacji danych i porządku w tabeli. Nie zgubią się też zera wiodące, które przy typach liczbowych potrafią zniknąć. Moim zdaniem, szczególnie w systemach produkcyjnych (np. system kadrowy, rejestr pacjentów, e‑sklep z weryfikacją danych klienta), taki zapis jest po prostu najbezpieczniejszy i najbardziej przewidywalny. W wielu firmowych standardach programistycznych jest wręcz zapisane wprost: PESEL, NIP, REGON, numery dokumentów, numery kart, kody pocztowe – zawsze trzymamy jako CHAR/VARCHAR, a nie jako INT czy inne typy numeryczne. Dodatkowo CHAR(11) jest efektywny wydajnościowo dla stałej długości: porównywanie, indeksowanie, sortowanie takiej kolumny jest proste dla silnika SQL. W razie potrzeby możesz też na takim polu założyć indeks unikalny (UNIQUE), żeby baza nie dopuściła do wprowadzenia dwóch takich samych PESEL‑i. To jest właśnie praktyczne połączenie typów danych z zasadami integralności i jakości danych, których oczekuje się w prawidłowo zaprojektowanych bazach.
W przypadku numeru PESEL kluczowe jest zrozumienie, że mamy do czynienia z identyfikatorem, a nie z liczbą, na której będziemy wykonywać obliczenia. To rozróżnienie jest bardzo ważne w projektowaniu baz danych, bo prowadzi do innego doboru typów danych. Częsty błąd polega na tym, że skoro PESEL składa się tylko z cyfr, to „na logikę” powinien być przechowywany jako typ liczbowy. W praktyce to podejście generuje więcej problemów niż pożytku. Typ TINYINT jest zdecydowanie zbyt mały – w większości systemów pozwala przechować zakres od 0 do 255 lub podobny, a PESEL ma 11 cyfr, więc nawet nie ma fizycznej możliwości, żeby taki typ pomieścił pełną wartość. To jest po prostu zupełnie nieadekwatny zakres. Z kolei użycie typu zmiennoprzecinkowego, takiego jak FLOAT(11), jest jeszcze gorszym pomysłem. Typ FLOAT służy do przybliżonego zapisu liczb rzeczywistych i może wprowadzać błędy zaokrągleń. W przypadku identyfikatora, który musi być zapisany dokładnie co do cyfry, jakikolwiek błąd reprezentacji jest niedopuszczalny. Dodatkowo typy zmiennoprzecinkowe nie gwarantują zachowania wszystkich cyfr w sposób bezstratny przy dużych wartościach, a PESEL ma ich 11. Można też natknąć się na problem utraty zer wiodących, bo liczby w SQL nie „pamiętają” formatu, tylko samą wartość liczbową. BLOB natomiast służy do przechowywania danych binarnych: plików, obrazów, dokumentów, zaszyfrowanych bloków danych. Używanie BLOB‑a do trzymania prostego tekstowego identyfikatora jest sprzeczne z dobrymi praktykami projektowania. Utrudnia to indeksowanie, wyszukiwanie, sortowanie i walidację, a do tego zużywa niepotrzebnie więcej zasobów. W profesjonalnych projektach baz danych przyjmuje się zasadę: dane tekstowe o znanej długości przechowujemy w typach znakowych (CHAR/VARCHAR), liczby do obliczeń w typach numerycznych, a typy binarne zostawiamy na pliki i dane nieustrukturyzowane. Błędne odpowiedzi wynikają zwykle z automatycznego kojarzenia „cyfry = liczba” i z braku rozróżnienia między wartością liczbową a identyfikatorem, który tylko składa się z cyfr, ale nie jest przeznaczony do liczenia. Właśnie dlatego optymalnym i zgodnym z dobrymi praktykami wyborem dla PESEL jest typ znakowy o stałej długości, czyli CHAR(11).