Który typ danych należy przypisać kolumnie z kodami pocztowymi w tabeli relacyjnej bazy danych, aby przechowywała dane w formie łańcuchów znakowych o zdefiniowanej, stałej długości?

Poprawnie – dla kolumny z kodami pocztowymi najlepszym wyborem jest typ CHAR. Kody pocztowe są danymi tekstowymi, a nie liczbowymi, mimo że często składają się wyłącznie z cyfr. W wielu krajach (np. w Polsce, Wielkiej Brytanii czy Kanadzie) kod pocztowy może zawierać myślniki, spacje, a nawet litery. Co ważne, długość kodu jest z góry znana i stała (np. w Polsce zawsze 6 znaków w formacie „NN-NNN”). Typ CHAR został właśnie zaprojektowany do przechowywania krótkich łańcuchów znaków o stałej długości. Silnik bazy danych rezerwuje stałą ilość miejsca i dopełnia wartość spacjami, jeśli jest krótsza. Dzięki temu porównywanie, indeksowanie i sortowanie takich pól jest przewidywalne i wydajne. Moim zdaniem jest to dokładnie ten przypadek, który się podręcznikowo podaje na zajęciach: PESEL, NIP, numer dokumentu, kod pocztowy – wszystkie to typowe przykłady na CHAR. W praktyce np. w MySQL zdefiniujesz taką kolumnę jako CHAR(6), w PostgreSQL jako CHAR(6) albo ewentualnie VARCHAR(6), ale przy stałej długości CHAR jest bardziej jednoznacznym sygnałem projektowym. Dodatkowo użycie typu znakowego zapobiega „obcinaniu” zer wiodących, co jest częstym błędem przy traktowaniu kodów pocztowych jako liczby. W wielu systemach legacy właśnie z tego powodu trzeba było później migrować typ danych z numerycznego na tekstowy. Z punktu widzenia dobrych praktyk modelowania danych przyjmuje się zasadę: jeżeli coś nie służy do liczenia, tylko jest identyfikatorem lub etykietą, to przechowujemy to jako tekst, a dla stałej długości – jako CHAR o odpowiednim rozmiarze.