AI og MySQL-databaser

Det er en betydelig feil at mange AI-genererte databaseskjemaer for tiden har en tendens til å bruke VARCHAR(36) for id kolonnen.

Dette er vanligvis motivert av et ønske om å forhindre uautorisert tilgang fra ondsinnede aktører. For å oppnå dette brukes UUID (Universal Unique Identifiers) ofte som en sikkerhetstiltak.

La oss ta WordPress som et eksempel — det avslører vanligvis innlegg-IDer i URL-en som ?p=45. Sammenlignet med et SEO-vennlig format som /2025/05/sample-post, lar denne numeriske ID-en brukere potensielt vurdere og få tilgang til tilstøtende innhold ved å endre nummeret (f.eks. ?p=44). UUID er derimot ikke-sekvensielle og betydelig vanskeligere å gjette.

UUID er 36-tegn strenger som følger et standardformat med fem seksjoner atskilt med bindestreker: 8-4-4-4-12. Hver seksjon består av heksadesimale verdier:

550e8400-e29b-41d4-a716-446655440000
f47ac10b-58cc-4372-a567-0e02b2c3d479
123e4567-e89b-12d3-a456-426614174000

En enkel regex for å validere UUID ser slik ut:

^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$

Selv om UUID gir sikkerhet og portabilitet, kommer de med kompromisser. De er betydelig større enn heltall, noe som kan redusere databaseytelsen — spesielt når de brukes som primærnøkler i relasjonsdatabaser. Indeksering, minnebruk og spørringshastighet lider alle på grunn av UUID-størrelse og ikke-sekvensielle natur.

AI-samtale om ID-strategi

Nysgjerrig på dette designvalget stilte jeg dette spørsmålet til GitHub Copilot:

Meg:
Hvorfor valgte du å definere id kolonnen som VARCHAR(36) PRIMARY KEY i databasestrukturen?

GitHub Copilot:

Jeg valgte VARCHAR(36) for ID-kolonner av flere spesifikke årsaker:

1. UUID-lagring: 36-tegn lengden passer UUID-verdier, som følger et standardisert format.
2. Multi-tenant systemer: UUID hjelper med å isolere leietakere ved å eliminere sekvensiell ID-lekkasje, forenkle migrasjoner og forbedre sikkerhet.
3. Dataportabilitet: UUID sikrer at eksporterte data ikke har ID-konflikter når de importeres til et annet system.

Kompromisser:

• Større lagringsstørrelse (36 bytes vs 4 bytes for INT)
• Tregere indeksering og spørringsytelse
• Høyere minnebruk

Alternativer å vurdere:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) for å lagre rå UUID-bytes mer effektivt
3. Tilpasset ID-genereringsstrategi

Gi meg beskjed hvis du foretrekker en annen tilnærming.

Meg:
Bruk BIGINT UNSIGNED for ytelse, men behold et guid felt i hver post for eksterne referanser.

GitHub Copilot:

Jeg vil oppdatere skjemaet til å bruke BIGINT UNSIGNED for primærnøkler og legge til en guid kolonne for eksterne referanser. Denne hybridtilnærmingen kombinerer det beste fra begge strategier:

• Ytelse: Effektiv indeksering og sammenkobling gjennom numeriske primærnøkler
• Sikkerhet og portabilitet: GUID eksponert i API-er, holder interne ID-er sikre fra opptelling

Sammendrag:

• BIGINT UNSIGNED: Rask, kompakt, sekvensiell
• GUID (VARCHAR): Unik, portabel, eksternt sikker

NoSQL-databaser og MongoDB ObjectIds

Mens relasjonsdatabaser tilbyr fleksibilitet i valg mellom UUID, heltall eller hybridtilnærminger, tar NoSQL-systemer som MongoDB en annen vei.

MongoDB bruker en innebygd type kalt ObjectId for sitt _id felt. Dette er en 12-byte binær verdi som koder:

• 4 bytes – Tidsstempel (sekunder fra epoch)
• 5 bytes – Tilfeldig verdi (ofte basert på maskin + prosess-ID)
• 3 bytes – Økning teller

Eksempel:

507f1f77bcf86cd799439011

Hvorfor MongoDB velger ObjectId

1. Globalt unik uten koordinering
   Som UUID krever ikke ObjectIds en sentral myndighet for å sikre unikhet, noe som gjør dem ideelle for distribuerte miljøer.
2. Tid-ordnet
   Det innebygde tidsstempelet betyr at dokumenter er i kronologisk rekkefølge som standard, noe som kan hjelpe ytelsen i tidsserie-spørringer.
3. Kompakt og effektiv
   Lagret i binært format tar ObjectIds bare 12 bytes — mye mindre enn UUID VARCHAR(36). De er også mer indekseringsvennlige.

Sammenligning av ID-strategier

AI-valg i NoSQL-kontekster

Mange AI-genererte systemer bruker NoSQL-konfigurasjoner som MongoDB som standard når:

• Høy skriving eller sharding forventes
• Skjemaer må være fleksible eller semi-strukturerte
• Dataportabilitet og distribuert skalering er prioriteter

I slike tilfeller er det ofte et fornuftig standardvalg å bruke ObjectIds eller lignende unike, tid-ordnede identifikatorer.

PrimeCRM