Générateur UUID v7

Pendant des années, les équipes d'ingénierie voulant la résistance aux collisions d'un UUID mais le tri amical pour l'indexation d'un entier séquentiel ont dû construire leur propre hybride non standard — préfixant couramment un UUID aléatoire avec un horodatage généré manuellement, une approche utilisée sous diverses formes par plusieurs entreprises de systèmes distribués connues avant qu'aucun standard officiel n'existe pour cela. La RFC 9562 a formalisé ce motif en une version officielle d'UUID spécifiquement pour que les implémentations à travers différents langages et bases de données puissent produire et reconnaître la même structure ordonnée dans le temps sans que chaque équipe réinvente indépendamment une variante légèrement différente et incompatible de la même idée.

Les 48 bits de tête d'un UUID v7 encodent un horodatage Unix en millisecondes, ce qui donne à la valeur son ordre de tri — comparer deux UUID v7 comme chaînes plates reflète correctement lequel a été généré en premier, la portion horodatage dominant la comparaison. Les bits restants demeurent remplis de données cryptographiquement aléatoires, exactement comme en v4, donc la valeur est tout aussi résistante à être devinée que le serait un UUID entièrement aléatoire ; seul son comportement de tri change, pas son imprévisibilité.

Au-delà de la vitesse d'insertion brute, une clé primaire ordonnée dans le temps a un second bénéfice pratique comptant au quotidien : les lignes reviennent naturellement dans l'ordre de création depuis une simple requête `ORDER BY id`, sans avoir besoin d'une colonne `created_at` séparée et d'un index supplémentaire dessus juste pour trier les enregistrements chronologiquement. Pour une table fréquemment interrogée « le plus récent d'abord » — un journal d'activité, une file, une piste d'audit — une clé primaire v7 donne ce tri gratuitement comme effet secondaire de l'ID lui-même, plutôt que comme un coût séparé à maintenir.