Hurtigere svar med et bedre valg af nøgle

Situation. Hver entitet har brug for et unikt id, og det oplagte standardvalg er en tilfældig UUID. Problemet er, at tilfældige id’er havner spredt ud over hele B‑tree‑indekset. Inserts spredes, indekset bliver fragmenteret, og efterhånden som tabellerne vokser, går det ud over både skrivninger og range‑scans. På en platform, der skal blive ved med at vokse, er det et langsomt, snigende tab, man helst ikke bygger ind fra starten.

Opgave. At bevare UUID’ens globale unikhed, men slippe af med den fragmentering, som tilfældigheden fører med sig.

Handling. Standarden blev UUID v7, som er tidsordnet — de forreste bits er et tidsstempel, så nye rækker lægger sig i rækkefølge i indekset i stedet for at blive strøet ud over det. PostgreSQL 18 har den indbygget som uuidv7(), og den er pakket ind i en lille uuid_generate_v7()-funktion, så det samme kald også fungerer rent på Azures Flexible Server; derefter blev den gjort til standard for entiteternes primærnøgler i hele skemaet. Intet eksotisk ved det; det er den slags beslutning, der er billig, hvis man træffer den tidligt, og besværlig at indføre bagefter.

Resultat. Id’erne forblev globalt unikke, indekset holdt op med at blive fragmenteret, sådan som tilfældige UUID’er forårsager, og tidsordnede inserts og range‑forespørgsler blev hurtigere — ensartet i alle tabeller, uden at nogen skulle tænke over det igen. Som en ekstra gevinst får hver entitet gratis en nøgle, der kan sorteres efter tid.