Wenn es um Textdaten in PostgreSQL geht, haben wir drei Hauptdarsteller: CHAR, VARCHAR und TEXT. Jeder davon hat seine eigenen Besonderheiten, Vorteile und Tücken. Lass uns das mal der Reihe nach anschauen.
CHAR(n)
CHAR, oder character, ist eine Zeichenkette mit fester Länge n. Wenn die Datenkette weniger Zeichen hat als angegeben, wird sie automatisch mit Leerzeichen aufgefüllt.
Beispiel:
| id | code - CHAR(5) |
|---|---|
| 1 | ''ABC'' |
Der Typ ist praktisch, wenn alle Strings die gleiche Länge haben sollen (zum Beispiel Codes, Barcodes oder IDs mit fester Länge).
Aber wenn du mit Texten variabler Länge arbeitest, nehmen die zusätzlichen Leerzeichen nur unnötig Platz in der Datenbank weg.
VARCHAR(n)
VARCHAR, oder variable character, ist für Zeichenketten variabler Länge gedacht, mit einer maximalen Begrenzung auf n Zeichen.
Beispiel:
| id | username - VARCHAR(10) |
|---|---|
| 1 | ''Alice'' |
Der Typ nutzt den Speicher effizient, weil nur der tatsächliche Text gespeichert wird. Ein Nachteil ist aber, dass du eine Längenbegrenzung angeben musst. Wenn der String diese Grenze überschreitet, wirft die Datenbank einen Fehler.
TEXT
TEXT ist ein Zeichenketten-Datentyp ohne Längenbegrenzung. Der Typ wird oft verwendet, wenn du nicht weißt, wie groß der Text werden kann.
Beispiel:
| id | content - TEXT |
|---|---|
| 1 | ''Das ist ein langer Text. Keine Limits!'' |
Vorteile: Du kannst Texte beliebiger Länge speichern, ohne dir über Begrenzungen Gedanken zu machen.
Nachteile: Keine Begrenzung kann dazu führen, dass die Datenbank ineffizient genutzt wird, wenn die Textdaten "aufgeblasen" werden.
Vergleich der Text-Datentypen
Wenn du mit Text arbeitest, ist es wichtig zu wissen, welcher Datentyp für deinen Fall passt. Hier die wichtigsten Unterschiede zwischen CHAR, VARCHAR und TEXT:
| Datentyp | Länge | Performance | Wann verwenden? |
|---|---|---|---|
CHAR(n) |
Fest | Schneller bei Strings mit fester Länge | Für Codes mit fester Länge (z.B. ISO) |
VARCHAR(n) |
Maximale Länge n |
Schneller als TEXT, wenn Länge begrenzt ist |
Für Strings variabler Länge mit bekanntem Maximum |
TEXT |
Unbegrenzt | Am vielseitigsten | Für lange Texte, deren Umfang schwer vorherzusagen ist |
Praktische Anwendungsbeispiele
Okay, schauen wir uns mal an, wie man diese Datentypen in echten Szenarien verwendet.
Beispiel 1: CHAR für Codes mit fester Länge
Stell dir vor, du arbeitest mit einer Datenbank, in der du Stadtkürzel nach ISO 3166-1 alpha-3 speichern musst. Jeder Code muss genau 3 Zeichen haben.
| city_id | city_name - VARCHAR(50) | iso_code - CHAR(3) |
|---|---|---|
| 1 | New York | NYC |
| 2 | Los Angeles | LAX |
| 3 | Chicago | CHI |
Hier ist CHAR(3) perfekt, weil jeder ISO-Code der Stadt genau die gleiche Länge hat.
Beispiel 2: VARCHAR für Usernamen
Ein Username ist ein super Anwendungsfall für VARCHAR. Normalerweise ist der Name variabel lang, aber du kannst davon ausgehen, dass er nie länger als 50 Zeichen wird.
| user_id | username - VARCHAR(50) | email - VARCHAR(50) |
|---|---|---|
| 1 | Alice | alice@example.com |
| 2 | Bob | bob@example.net |
VARCHAR spart hier Speicher, weil die tatsächliche Länge des Strings oft unter 50 Zeichen liegt.
Beispiel 3: TEXT für Beschreibungen
Stell dir vor, du hast einen Blog, in dem du für jeden Post eine große Textbeschreibung speichern musst. Hier ist TEXT die beste Wahl.
| post_id | title - VARCHAR(100) | content - TEXT |
|---|---|---|
| 1 | Post 1 | This is a very long blog post content that goes on and on... |
Wenn du nie vorher weißt, wie lang der Text wird, ist TEXT einfach ideal.
4. Weitere Details und Stolperfallen
Beim Arbeiten mit Text-Datentypen gibt es ein paar Dinge, auf die du achten solltest, damit du typische Fehler vermeidest.
Problem: CHAR fügt Leerzeichen hinzu
Wenn du Strings in einem CHAR-Feld vergleichst, ohne die angehängten Leerzeichen zu beachten, kann das zu unerwarteten Ergebnissen führen.
SELECT * FROM cities WHERE iso_code = 'NYC';
-- Es kommt nichts zurück, wenn du die Leerzeichen nicht entfernst
So löst du das: Benutze die Funktion TRIM(), um die Leerzeichen zu entfernen.
SELECT * FROM cities WHERE TRIM(iso_code) = 'NYC';
Problem: Längenbegrenzung bei VARCHAR kann Fehler verursachen
Wenn du versuchst, einen String in ein VARCHAR-Feld einzufügen, der zu lang ist, wirft die Datenbank einen Fehler.
INSERT INTO users (username, email) VALUES ('A_username_that_is_too_long_for_field', 'test@example.com');
-- Fehler
So löst du das: Stelle sicher, dass die Längenbegrenzung (n) zu deinen echten Anforderungen passt. Oder benutze TEXT, um Begrenzungen zu vermeiden.
Problem: TEXT kann deine Datenbank aufblähen
TEXT speichert unbegrenzt Daten, was dazu führen kann, dass Tabellen zu groß werden und das Indexieren schwieriger wird.
Wie vermeiden: Wenn du planst, eine TEXT-Spalte stark zu indexieren, überlege, ob ein begrenztes VARCHAR nicht besser wäre.
GO TO FULL VERSION