Eine klassische Datenbank kann fortlaufende IDs vergeben, solange jede Erstellung zuerst dieselbe Instanz erreicht. In verteilten Anwendungen möchten mobile Clients, Importer und mehrere Dienste jedoch oft schon vor dem zentralen Insert eine stabile Identität besitzen. UUIDs lösen genau dieses Vergabeproblem: Jeder Teilnehmer kann aus einem sehr großen Namensraum selbst einen Wert erzeugen, ohne vorher eine Nummer zu reservieren.

Eine UUID enthält 128 Bits

Die bekannte Textform besteht aus 32 Hexzeichen in fünf Gruppen, etwa 550e8400-e29b-41d4-a716-446655440000. Die Bindestriche verbessern Lesbarkeit; der eigentliche Wert umfasst 16 Bytes. Bestimmte Bits beschreiben Version und Variante, die übrigen folgen dem jeweiligen Erzeugungsverfahren.

Die kanonische Textform sollte an API-Grenzen einheitlich sein. Datenbanken können intern einen nativen UUID-Typ oder 16 Binärbytes verwenden, um Platz und Indexgröße gegenüber einem allgemeinen Textfeld zu sparen.

Der große Namensraum ersetzt die zentrale Vergabe

Bei zufälligen UUIDv4 stehen nach den reservierten Bits 122 Zufallsbits zur Verfügung. Das Kollisionsrisiko bleibt bei korrekt erzeugten Werten selbst für sehr große Mengen extrem klein. Die Garantie ist probabilistisch, aber praktisch stark genug für übliche Systeme.

Diese Eigenschaft ermöglicht Offline-Erstellung, parallele Imports und das Zusammenführen unabhängiger Datenbestände. Ein Objekt kann bereits in Events, Dateien und Beziehungen referenziert werden, bevor es eine zentrale Datenbank erreicht.

Die Qualität des Generators ist entscheidend

Der riesige Raum hilft nicht, wenn ein fehlerhafter Zufallszahlengenerator immer dieselbe Sequenz liefert. Anwendungen sollten gepflegte UUID-Bibliotheken und kryptografisch geeignete Systemzufälligkeit verwenden. Eigene Konstruktionen aus Timestamp, Prozess-ID und kurzer Zufallszahl verkleinern den Raum und können Informationen offenlegen.

Ein Duplicate-Key-Fehler ist deshalb nicht einfach als astronomischer Zufall abzutun. Er kann auf geklonte Zustände, falsche Fixtures oder einen ersetzten Generator hinweisen und verdient Telemetrie.

Versionen verteilen Bits nach unterschiedlichen Regeln

UUIDv4 ist weitgehend zufällig. UUIDv7 kombiniert einen Unix-Zeitanteil mit Zufallsbits und ist ungefähr zeitlich sortierbar. Namensbasierte Versionen erzeugen für denselben Namespace und Namen deterministisch denselben Wert. Ältere zeitbasierte Varianten besitzen andere Datenschutz- und Betriebsmerkmale.

Eine UUID ist daher nicht nur „irgendeine lange ID“. Der Vertrag sollte festlegen, welche Version erzeugt wird und welche Versionen eingehend akzeptiert werden.

Unabhängige Erzeugung verändert Workflows

Ein Client kann eine ID vor dem Upload vergeben und bei einem Retry wiederverwenden. Das erleichtert idempotente Erstellung: Der zweite Versuch zielt auf dieselbe Identität statt auf ein neues Objekt. Beziehungen zwischen mehreren neuen Datensätzen können bereits lokal aufgebaut werden.

Die UUID allein verhindert jedoch keine doppelte fachliche Aktion. Wenn jeder Retry einen neuen Wert erzeugt, entstehen weiterhin Duplikate. Die Identität der Absicht muss über Versuche stabil bleiben.

UUIDs sind keine Geheimnisse

Ein zufälliger Wert ist schwer zu erraten, kann aber in URLs, Logs, Browserhistorien und Supporttickets erscheinen. Ein API-Endpoint muss für jede ID Berechtigung und Tenant prüfen. „Wer die UUID kennt, darf lesen“ ist nur dann vertretbar, wenn die ID bewusst als Capability-Token mit entsprechendem Lebenszyklus entworfen wurde.

Meist sollte ein separater Zugriffstoken verwendet werden, der widerrufen und ablaufen kann. Die dauerhafte Identität eines Objekts hat andere Anforderungen.

Öffentliche und interne IDs können nebeneinander bestehen

Eine Datenbank kann einen kompakten sequenziellen Primärschlüssel für Joins und zusätzlich eine UUID für externe APIs besitzen. Diese Trennung schützt nicht automatisch vor Datenlecks, ermöglicht aber unabhängige Optimierung von Storage und öffentlichem Vertrag.

Feldnamen und Typen müssen eindeutig sein. Wenn Code interne und öffentliche IDs verwechselt, entstehen falsche Beziehungen oder Autorisierungsfehler. Eine zusätzliche Mapping-Schicht verursacht ebenfalls Kosten und sollte einen konkreten Nutzen haben.

Textnormalisierung verhindert logische Duplikate

Hexbuchstaben können in verschiedener Großschreibung erscheinen, manche Systeme akzeptieren Formen ohne Bindestriche oder mit Klammern. Intern repräsentieren sie möglicherweise denselben Wert. Eine API sollte eine kanonische Ausgabe besitzen und Eingaben mit einer echten UUID-Bibliothek parsen.

Blindes „Reparieren“ abgeschnittener oder mit Zusatztext versehener Werte ist gefährlich. Ungültige Identität wird abgelehnt; erlaubte alternative Darstellungen werden nach erfolgreichem Parsing normalisiert.

Indexverhalten hängt von Version und Engine ab

Vollständig zufällige Primärschlüssel führen Inserts an verschiedene Stellen eines geordneten B-Tree-Index. Bei hoher Schreibrate kann das Page Splits, Cache Misses und Fragmentierung erhöhen. Wie stark der Effekt ist, hängt von Datenbank, Schema und Hardware ab.

Zeitlich sortierbare UUIDv7 oder ein interner sequenzieller Schlüssel können helfen. Die Entscheidung sollte mit realistischen Inserts, Joins, Replikation und Backups gemessen werden, nicht nur mit der Geschwindigkeit der ID-Erzeugung.

Sortierbarkeit ersetzt kein Zeitfeld

Der Zeitanteil einer UUIDv7 macht Werte praktisch ordnungsfreundlicher, stammt aber aus der Uhr des Erzeugers. Clock-Skew und gleichzeitige Erstellung bleiben möglich. Für Audit, fachliche Zeit und SLA braucht das Modell weiterhin explizite Felder wie created_at.

Die UUID optimiert Identität und gegebenenfalls Indexlokalität. Sie sollte nicht still mehrere fachliche Bedeutungen übernehmen.

Migrationen brauchen ein dauerhaftes Mapping

Beim Zusammenführen alter Systeme darf derselbe Quelldatensatz nicht bei jedem Import eine neue UUID erhalten. Eine Zuordnung aus Quellsystem, alter ID und neuer UUID macht Wiederholungen deterministisch und erhält Referenzen.

Bestehende veröffentlichte IDs sollten möglichst nicht umgeschrieben werden. Neue Datensätze können eine neue Version verwenden, während Validatoren in der Übergangszeit beide akzeptieren.

UUID löst Vergabe, nicht das gesamte Datenmodell

Unique Constraints, Foreign Keys, Berechtigungen, Idempotenz und Aufbewahrung bleiben notwendig. UUIDs beseitigen einen zentralen Nummernverteiler und ermöglichen stabile Identität vor dem Speichern. Genau diese begrenzte Aufgabe erfüllen sie sehr gut.

Ein belastbarer Einsatz dokumentiert Version, Generator, kanonische Form, Datenbanktyp und Lebenszyklus. Dann wird aus der langen Zeichenfolge ein verlässlicher Vertrag statt einer dekorativen Zufallsnummer.