Beim Entwurf einer API mit Postgres oder MySQL kommt früher oder später die Frage: Auto-Increment-Schlüssel oder UUID? Hier der Vergleich, mit dem wir bei Toolbrik entschieden haben.
UUID v4 (zufällig)
- Vorteile: verrät nichts über Geschäftsvolumen oder Reihenfolge; wird clientseitig ohne Round-Trip erzeugt; praktisch unmöglich zu erraten (122 Bit Entropie).
- Nachteile: verstreute Indexseiten in B-Trees (geringere Cache-Dichte); 36 Zeichen Text.
UUID v1 (zeitbasiert)
- Vorteile: ungefähre zeitliche Reihenfolge, nützlich für Event Sourcing oder Partitionierung nach Datum.
- Nachteile: verrät das Erstellungsdatum und, je nach Implementierung, den erzeugenden Knoten. Erratbar bei einem festen Knoten.
Fortlaufende IDs
- Vorteile: kompakte, schnelle Indizes, einfaches Debugging, saubere URLs (
/users/42). - Nachteile: aufzählbar — jeder kann deine Ressource systematisch durchgehen; benötigen den Server zur Erzeugung; ein Concurrency-Bug kann sie duplizieren.
Praktische Empfehlung
- Nutze UUID v4 als Standard-Primärschlüssel.
- Erzeuge UUIDs serverseitig, wenn du die Reihenfolge verbergen willst, oder clientseitig für null Latenz.
- Für Event-Tabellen lohnt sich v1; für interne Kataloge ist eine Sequenz durchaus vertretbar.
- Speichere die UUID IMMER als nativen
uuid-Typ, nicht alsvarchar, und nutze sie als Cache-Schlüssel.
UUIDs aus unsicheren Quellen normalisieren
Nicht jedes System liefert UUIDs im gleichen Format: Großbuchstaben, das Präfix urn:uuid: mancher Standards (WSDL, ATOM) oder 32-stellige Zeichenketten ohne Bindestriche kommen alle vor. Der UUID-Validator akzeptiert alle drei Varianten, erkennt Version und Variante (RFC 4122 vs. reserviert) und normalisiert sie vor dem Speichern auf die kanonische Kleinschreibform.
Erzeuge so viele wie nötig mit unserem UUID-Generator (v4 und v1, mit oder ohne Bindestriche) und validiere jede Liste mit dem Validator, bevor du sie committest.