Erzeuge sortierbare, 26-stellige ULIDs (Crockford Base32) und dekodiere den eingebetteten Timestamp zurück in ein Datum. Hervorragend für Datenbank-Primärschlüssel.
Sortierbare eindeutige Identifikatoren. Ein ULID besteht aus 26 Zeichen: die ersten 10 codieren die Erstellungszeit in Millisekunden, die letzten 16 sind zufällig. Das macht sie lexikografisch sortierbar und sicher als Schlüssel verwendbar. Im Browser generiert.
Ein ULID ist ein 128-Bit-Identifier, genauso breit wie ein UUID, aufgeteilt in zwei Teile: ein 48-Bit-Millisekunden-Timestamp gefolgt von 80 Zufallsbits. Er wird als 26 Zeichen Crockford Base32 gerendert statt als die 36 Zeichen lange, durch Bindestriche getrennte Hex-Form eines UUID, also ist er kürzer, groß-/kleinschreibungsunabhängig und frei von den am leichtesten verwechselten Zeichen – I, L, O und U sind alle aus dem Alphabet ausgeschlossen. Der entscheidende Unterschied ist nicht die Codierung, es ist die Reihenfolge. Weil der Timestamp die hohen Bits belegt und Base32 die Byte-Reihenfolge bewahrt, sortiert das Sortieren von ULIDs als Klartext sie nach Erstellungszeit. Zwei IDs, die in derselben Millisekunde erzeugt wurden, fallen auf ihren Zufallsteil zurück, aber über Millisekunden hinweg ist die Reihenfolge exakt.
UUIDv4 ist gleichmäßig zufällig, was genau das ist, was du in einem gruppierten Index nicht willst. Jeder Insert landet an einem zufälligen Punkt im B-Baum, sodass die Datenbank ständig Seiten aufteilt und kalte berührt. Der Index wächst größer als nötig, und der Schreibdurchsatz verschlechtert sich mit wachsender Tabelle. Das ist ein gut dokumentiertes Problem mit UUID-Primärschlüsseln in MySQLs InnoDB und in SQL Server. Ein zeitgeordneter Identifier hängt nahe am rechten Rand des Index an, was dasselbe Zugriffsmuster ist wie ein Auto-Increment-Integer. Du behältst die Vorteile eines client-generierten global eindeutigen Schlüssels – kein Round-Trip, um eine ID zu bekommen, keine Koordination zwischen Services, sichere Merges über Shards –, ohne die Index-Fragmentierung.
UUIDv7, standardisiert in RFC 9562, macht dasselbe wie ULID im standardisierten UUID-Format und -Layout. Wenn dein Stack bereits native UUID-Spalttypen und -Tooling hat, ist UUIDv7 jetzt meist die bessere Wahl, einfach weil es in das bestehende Ökosystem fällt. ULID bleibt attraktiv, wenn du die kürzere, freundlichere Textform in URLs oder Logs willst. Egal wie, sei dir klar, dass der Timestamp für jeden sichtbar ist, der die ID hält. Erstellungszeiten lassen sich ableiten, und benachbarte IDs verraten die Reihenfolge – verwende diese nicht für etwas, bei dem die Aufzählung oder die Zeitangabe sensibel ist. Und mit 80 Zufallsbits pro Millisekunde sind Kollisionen kein praktisches Problem, aber ULIDs sind keine Geheimnisse und sollten niemals als Capability-Token verwendet werden.