5 typische UUID-Fehler in Code-Reviews — und wie du sie vermeidest

UUIDs wirken auf den ersten Blick simpel: irgendein zufälliger String, fertig. In echten Code-Reviews tauchen aber immer wieder dieselben fünf Stolperfallen auf — vom falschen Spaltentyp bis zur verwechselten Version. Dieser Leitfaden geht sie einzeln durch, mit einem hypothetischen Beispiel-Szenario zu jedem Punkt.

Fehler 1: UUID als VARCHAR(36) statt Binärtyp speichern

KurzantwortEin UUID-String belegt als VARCHAR(36) deutlich mehr Speicherplatz als die zugrunde liegenden 16 Byte und lässt sich langsamer vergleichen und indexieren als ein nativer Binär- oder UUID-Spaltentyp.

Angenommenes Beispiel-Szenario: Ein Reviewer sieht in einem Pull-Request eine neue Tabelle mit id VARCHAR(36) PRIMARY KEY, obwohl die verwendete Datenbank einen nativen UUID-Typ (PostgreSQL) oder BINARY(16) (MySQL) anbietet. Das funktioniert zwar, verschenkt aber Platz — 36 Zeichen als String benötigen typischerweise mehr Bytes als die reinen 16 Byte der UUID — und macht Indexvergleiche etwas aufwendiger, weil String-Vergleiche in der Regel mehr Rechenaufwand verursachen als der Vergleich fester Binärblöcke.

Die Korrektur ist meist unkompliziert: Spaltentyp auf den nativen UUID- oder Binärtyp der jeweiligen Datenbank umstellen und die Konvertierung beim Lesen/Schreiben der Anwendung überlassen. Für schnelle Zwischentests eignet sich der UUID-Generator, um mit der Bulk-Funktion (bis zu 1.000 Werte) realistische Testdaten für beide Spaltentypen zu erzeugen und Speicherverbrauch/Antwortzeiten selbst zu vergleichen.

Fehler 2: v1-UUIDs in öffentlichen URLs verwenden

KurzantwortEine echte v1-UUID kann Erstellungszeitpunkt und Geräteinformationen preisgeben — für öffentlich sichtbare IDs sind v4 oder v7 in der Regel die sicherere Wahl.

Angenommenes Beispiel-Szenario: Ein Entwickler baut einen öffentlichen Freigabe-Link für ein Dokument nach dem Muster /share/<uuid> und generiert dafür versehentlich eine echte v1-UUID statt v4. Ein aufmerksamer Reviewer merkt an, dass sich aus dem Zeitstempel-Teil einer v1-UUID der ungefähre Erstellungszeitpunkt des Datensatzes ablesen lässt — für die meisten Anwendungen ein unnötiges, leicht vermeidbares Informationsleck.

Für öffentlich sichtbare IDs: v4 (rein zufällig, keine Zeit- oder Geräteinformation) oder v7 (nur ein grober Zeitstempel, keine Geräte-ID).
Für interne Datenbank-Primärschlüssel: v7 kann wegen der Sortierbarkeit sinnvoll sein, siehe den ersten Blog-Beitrag zu diesem Tool.
Der „v1-ähnliche" Modus in diesem Generator: verwendet ohnehin nur eine zufällig erzeugte Node-ID statt einer echten MAC-Adresse — nützlich zum Testen von v1-Parsing-Code, ohne echte Gerätedaten preiszugeben.

Fehler 3: Uneinheitliche Formatierung im Team

KurzantwortGroß-/Kleinschreibung, Bindestriche und geschweifte Klammern sind reine Formatierungsfragen — ohne eine zentrale Normalisierung im Code führen sie zu fehlschlagenden String-Vergleichen zwischen identischen UUIDs.

Angenommenes Beispiel-Szenario: Ein Frontend-Team erzeugt UUIDs ohne Bindestriche für kürzere URLs, während der Backend-Service sie im Standardformat mit Bindestrichen erwartet. Ein einfacher if (idFromUrl === idFromDb)-Vergleich schlägt fehl, obwohl beide dieselbe UUID repräsentieren — nur eben unterschiedlich formatiert.

Praktische RegelLege pro Projekt genau ein kanonisches Format fest (typischerweise Kleinbuchstaben mit Bindestrichen, 36 Zeichen) und normalisiere jede eingehende UUID an einer zentralen Stelle darauf, bevor sie verglichen, gespeichert oder weitergereicht wird.

Der UUID-Generator bietet genau diese Formatoptionen nebeneinander an (Klein-/Großbuchstaben, mit/ohne Bindestriche, geschweifte Klammern, URN-Präfix) — praktisch, um schnell zu prüfen, wie derselbe Wert in unterschiedlichen Darstellungen aussieht, bevor eine Formatentscheidung im Code festgeschrieben wird.

Format	Beispiel	Zeichenlänge
Standard (Kleinbuchstaben, mit Bindestrichen)	550e8400-e29b-41d4-a716-446655440000	36
Ohne Bindestriche	550e8400e29b41d4a716446655440000	32
Geschweifte Klammern (.NET GUID)	{550e8400-e29b-41d4-a716-446655440000}	38

Fehler 4 & 5: Fehlende Validierung und Versionsverwechslung

KurzantwortNicht jede 36-Zeichen-Zeichenkette mit Bindestrichen ist eine gültige UUID — Versions- und Varianten-Bits sollten geprüft werden, und die NIL-UUID sollte nicht stillschweigend als gültiger Wert durchgehen.

Angenommenes Beispiel-Szenario: Ein API-Endpunkt akzeptiert eine UUID als Pfad-Parameter und prüft nur grob per Regex auf 36 Zeichen mit Bindestrichen an den richtigen Stellen, ohne die Versions- und Varianten-Bits (Zeichen 15 bzw. die ersten 1-2 Bit von Zeichen 20) zu kontrollieren. Ein zufällig oder böswillig erzeugter String, der dem Muster entspricht, aber keine gültige RFC-4122-UUID ist, kommt so ungeprüft durch.

Eng verwandt ist eine Versionsverwechslung: Etwa wenn Code, der einen Zeitstempel aus einer UUID extrahieren soll, versehentlich auf eine v4- oder v3/v5-UUID angewendet wird — diese enthalten schlicht keine Zeitinformation, ein Extraktionsversuch liefert dann bestenfalls Datenmüll, schlimmstenfalls einen unbemerkt falschen Zeitstempel.

Praktischer Test: Füge eine beliebige UUID in den Reiter „Validieren" des Generators ein. Das Tool zeigt Version und Variante an und dekodiert bei v1, v7 und ULID zusätzlich den eingebetteten Zeitstempel in UTC und Lokalzeit — eine schnelle Methode, um Validierungs- oder Extraktionslogik gegenzuprüfen, bevor sie in Produktionscode landet.

UUIDs generieren, validieren und in verschiedenen Formaten vergleichen — direkt im Browser, ganz ohne Serveranfrage.

Zum UUID-Generator →

Häufig gestellte Fragen

Sollte ich UUIDs in der Datenbank als String oder als Binärtyp speichern?

Wenn deine Datenbank einen nativen UUID- oder Binärtyp anbietet (z. B. PostgreSQLs UUID-Typ oder BINARY(16) in MySQL), ist das fast immer die bessere Wahl gegenüber VARCHAR(36). Ein nativer 16-Byte-Typ spart Speicherplatz, ist schneller zu vergleichen und zu indexieren als eine 36-Zeichen-Zeichenkette. VARCHAR(36) ist nur dann vertretbar, wenn die Datenbank keinen passenden Binärtyp unterstützt oder die menschliche Lesbarkeit beim direkten Debuggen wichtiger ist als Performance.

Ist es ein Fehler, v1-UUIDs für öffentlich sichtbare IDs zu verwenden?

Ja, in den meisten Fällen. Eine klassische v1-UUID enthält einen echten Zeitstempel und potenziell eine Node-ID, die von einer MAC-Adresse abgeleitet ist. Wird eine solche ID in einer öffentlichen URL oder API-Antwort exponiert, lässt sich daraus theoretisch der Erstellungszeitpunkt des Datensatzes ablesen — meist ein ungewollter Informationsabfluss. Für öffentlich sichtbare IDs sind v4 (zufällig) oder v7 (nur Zeitstempel, keine Geräteinformation) die sicherere Wahl. Der „v1-ähnliche" Modus in diesem Tool verwendet ohnehin nur eine zufällig erzeugte Node-ID statt einer echten MAC-Adresse.

Warum landen in meinem Team manchmal UUIDs ohne Bindestriche und manchmal mit in derselben Datenbank?

Das passiert meist, wenn verschiedene Teammitglieder oder Services unterschiedliche Formatierungsoptionen beim Generieren wählen, ohne dass eine einheitliche Konvention im Code erzwungen wird. Die zugrunde liegenden 128 Bit sind identisch, aber ein String-Vergleich zwischen „ohne Bindestriche" und „mit Bindestrichen" schlägt fehl, selbst wenn es dieselbe UUID ist. Die Lösung ist, im Code an einer zentralen Stelle (z. B. beim Schreiben in die Datenbank) immer auf ein einziges Format zu normalisieren, unabhängig davon, in welchem Format eine UUID hereinkommt.

Kann ich v4- und v7-UUIDs in derselben Tabelle mischen?

Technisch ja — beide sind gültige 128-Bit-UUIDs und lassen sich problemlos in derselben Spalte speichern. Der Nachteil ist, dass du dann den Sortiervorteil von v7 verlierst, sobald auch nur ein Teil der Zeilen v4-Werte enthält, weil sich die zeitliche Reihenfolge nicht mehr zuverlässig aus dem Schlüssel ablesen lässt. Für neue Tabellen ist es sauberer, sich pro Tabelle für genau eine Version zu entscheiden und diese Entscheidung z. B. in einer Kommentarzeile am Schema zu dokumentieren.

Was übersehen Entwickler am häufigsten beim Testen von UUID-Generierungscode?

Ein häufig übersehener Fall ist die NIL-UUID (32 Nullen, 00000000-0000-0000-0000-000000000000) als möglicher, aber ungültiger Platzhalterwert — Validierungslogik sollte sie explizit abfangen, statt sie stillschweigend als gültige v4-UUID durchzulassen. Ebenso wird beim Testen oft vergessen, Groß-/Kleinschreibung zu berücksichtigen: RFC 4122 erlaubt sowohl Klein- als auch Großbuchstaben in Hex-Zeichen, ein reiner Zeichenketten-Vergleich ohne Normalisierung kann daher fälschlich zwei identische UUIDs als unterschiedlich behandeln.

Hinweis zur Methodik: Dieser Artikel dient der allgemeinen Information zu typischen UUID-Implementierungsfehlern gemäß RFC 4122/9562 und ersetzt keine individuelle Architektur- oder Sicherheitsberatung. Die beschriebenen Code-Review-Szenarien sind angenommene, illustrative Beispiele und keine dokumentierten Fälle eines konkreten Projekts.