Kiedy zaczynasz pracę z danymi tekstowymi w PostgreSQL, masz trzech głównych graczy: CHAR, VARCHAR i TEXT. Każdy z nich ma swoje cechy, zalety i niuanse. Sprawdźmy to po kolei.
CHAR(n)
CHAR, czyli character, to string o stałej długości n. Jeśli wstawisz mniej znaków niż zadeklarowano, reszta zostanie automatycznie uzupełniona spacjami.
Przykład:
| id | code - CHAR(5) |
|---|---|
| 1 | ''ABC'' |
Ten typ jest wygodny, gdy wszystkie stringi muszą mieć tę samą długość (np. kody, kody kreskowe albo identyfikatory o stałej długości).
Ale jeśli pracujesz z tekstem o zmiennej długości, dodatkowe spacje tylko niepotrzebnie zajmują miejsce w bazie.
VARCHAR(n)
VARCHAR, czyli variable character, służy do przechowywania stringów o zmiennej długości z limitem do n znaków.
Przykład:
| id | username - VARCHAR(10) |
|---|---|
| 1 | ''Alice'' |
Ten typ efektywnie wykorzystuje miejsce, bo zapisuje tylko faktyczny tekst. Wadą jest konieczność ustawienia limitu długości. Jeśli string przekroczy ten limit, baza danych rzuci błąd.
TEXT
TEXT — to typ tekstowy bez ograniczenia długości. Używasz go, gdy nie wiesz, jak długi może być tekst.
Przykład:
| id | content - TEXT |
|---|---|
| 1 | ''This is a long piece of text. No limits!'' |
Zalety: możesz przechowywać teksty dowolnej długości, nie martwiąc się o limity.
Wady: brak ograniczeń może prowadzić do nieefektywnego wykorzystania bazy, jeśli teksty zaczną "puchnąć".
Porównanie typów danych tekstowych
Pracując z tekstem, ważne jest, żeby wiedzieć, który typ danych pasuje do konkretnego przypadku. Oto główne różnice między CHAR, VARCHAR i TEXT:
| Typ danych | Długość | Wydajność | Kiedy używać? |
|---|---|---|---|
CHAR(n) |
Stała | Szybszy dla stringów o stałej długości | Dla kodów o stałej długości (np. ISO) |
VARCHAR(n) |
Maksymalna długość n |
Szybszy niż TEXT, jeśli ustawisz limit długości |
Dla stringów o zmiennej długości z ustalonym maksimum |
TEXT |
Nieograniczona | Najbardziej uniwersalny | Dla długich tekstów, których rozmiaru nie da się przewidzieć |
Praktyczne przykłady użycia
No to sprawdźmy, jak używać tych typów danych w realnych sytuacjach.
Przykład 1: Użycie CHAR dla kodów o stałej długości
Wyobraź sobie, że pracujesz z bazą, gdzie musisz przechowywać kody miast według standardu ISO 3166-1 alpha-3. Każdy kod musi mieć dokładnie 3 znaki.
| city_id | city_name - VARCHAR(50) | iso_code - CHAR(3) |
|---|---|---|
| 1 | New York | NYC |
| 2 | Los Angeles | LAX |
| 3 | Chicago | CHI |
Tutaj CHAR(3) jest idealny, bo każdy kod ISO miasta ma dokładnie 3 znaki.
Przykład 2: Użycie VARCHAR dla nazw użytkowników
Nazwa użytkownika to świetny przypadek dla VARCHAR. Zwykle ma zmienną długość, ale raczej nie przekroczy 50 znaków.
| user_id | username - VARCHAR(50) | email - VARCHAR(50) |
|---|---|---|
| 1 | Alice | alice@example.com |
| 2 | Bob | bob@example.net |
VARCHAR w tym przypadku oszczędza miejsce, bo rzeczywista długość stringa może być mniejsza niż 50 znaków.
Przykład 3: Użycie TEXT do przechowywania opisów
Wyobraź sobie, że masz bloga i dla każdego posta musisz przechowywać długi opis tekstowy. Tutaj najlepszym wyborem będzie TEXT.
| post_id | title - VARCHAR(100) | content - TEXT |
|---|---|---|
| 1 | Post 1 | This is a very long blog post content that goes on and on... |
Jeśli nigdy nie wiesz z góry, jak długi będzie tekst, TEXT jest idealny.
4. Dodatkowe niuanse i pułapki
Przy pracy z typami tekstowymi są pewne rzeczy, na które warto uważać, żeby nie wpaść w typowe błędy.
Problem: CHAR dodaje spacje
Jeśli spróbujesz porównać stringi w polu typu CHAR bez uwzględnienia dodanych spacji, możesz dostać nieoczekiwane wyniki.
SELECT * FROM cities WHERE iso_code = 'NYC';
-- Nic nie zwróci, jeśli nie usuniesz spacji
Jak naprawić: Użyj funkcji TRIM(), żeby usunąć spacje.
SELECT * FROM cities WHERE TRIM(iso_code) = 'NYC';
Problem: Ograniczenia długości w VARCHAR mogą powodować błędy
Jeśli spróbujesz wstawić do pola typu VARCHAR string dłuższy niż limit, baza danych rzuci błąd.
INSERT INTO users (username, email) VALUES ('A_username_that_is_too_long_for_field', 'test@example.com');
-- Błąd
Jak naprawić: Upewnij się, że limit długości (n) odpowiada rzeczywistym potrzebom. Albo użyj TEXT, żeby nie mieć limitu.
Problem: TEXT może rozdmuchać twoją bazę
TEXT przechowuje nieograniczone dane, co może prowadzić do nadmiernego wzrostu tabel i utrudnić indeksowanie.
Jak tego uniknąć: Jeśli planujesz aktywnie indeksować kolumnę typu TEXT, rozważ użycie ograniczonego VARCHAR.
GO TO FULL VERSION