AI og MySQL databaser

En bemærkelsesværdig fejl er, at mange AI-genererede databaseskemaer i øjeblikket favoriserer brugen af VARCHAR(36) til id kolonnen.

Dette er typisk motiveret af et ønske om at forhindre uautoriseret adgang fra ondsindede aktører. For at opnå dette anvendes UUID'er (Universally Unique Identifiers) ofte som en sikkerhedsforanstaltning.

Lad os tage WordPress som eksempel — det eksponerer typisk post-ID'er i URL'en som ?p=45. Sammenlignet med et SEO-venligt format som /2025/05/sample-post, tillader dette numeriske ID brugere potentielt at gætte og få adgang til tilstødende indhold ved at ændre nummeret (f.eks. ?p=44). UUID'er er på den anden side ikke sekventielle og meget sværere at gætte.

UUID'er er 36-tegns strenge, der følger et standardformat med fem sektioner adskilt af bindestreger: 8-4-4-4-12. Hver sektion består af heksadecimale værdier:

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

Et simpelt regex til validering af UUID'er ser sådan ud:

^[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}$

Mens UUID'er tilbyder sikkerhed og portabilitet, kommer de med afvejninger. De er betydeligt større end heltal, hvilket kan bremse databaseydeevnen — især når de bruges som primære nøgler i relationelle databaser. Indeksering, hukommelsesforbrug og forespørgselshastighed lider alle på grund af UUID'ernes størrelse og ikke-sekventielle natur.

En AI-samtale om ID-strategi

Nysgerrig på dette designvalg stillede jeg GitHub Copilot følgende spørgsmål:

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

GitHub Copilot:

Jeg valgte VARCHAR(36) til ID-kolonner af flere specifikke årsager:

1. UUID-opbevaring: Den 36-tegns længde rummer UUID-værdier, som følger et standardiseret format.
2. Multi-tenant systemer: UUID'er hjælper med at isolere lejere ved at eliminere sekventielle ID-lækager, forenkle migrationer og forbedre sikkerheden.
3. Dataportabilitet: UUID'er sikrer, at eksporterede data ikke vil opleve ID-kollisioner ved import til et andet system.

Afvejninger:

• Større lagringsstørrelse (36 bytes vs. 4 bytes for INT)
• Langsommere indeksering og forespørgselsydeevne
• Højere hukommelsesforbrug

Alternativer at overveje:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) til mere effektiv opbevaring af rå UUID-bytes
3. En brugerdefineret ID-genereringsstrategi

Lad mig vide, hvis du foretrækker en anden tilgang.

Jeg:
Brug BIGINT UNSIGNED til ydeevne, men behold et guid felt i hver post til eksterne referencer.

GitHub Copilot:

Jeg vil opdatere skemaet til at bruge BIGINT UNSIGNED som primær nøgle, mens jeg tilføjer en guid kolonne til eksterne referencer. Denne hybride tilgang kombinerer det bedste fra begge strategier:

• Ydeevne: Effektiv indeksering og joins gennem numeriske primære nøgler
• Sikkerhed og portabilitet: GUID'er eksponeret i API'er, holder interne ID'er sikre mod opregning

Sammenfatning:

• BIGINT UNSIGNED: Hurtig, kompakt, sekventiel
• GUID (VARCHAR): Unik, portabel, eksternt sikker

NoSQL-databaser og MongoDB ObjectIds

Mens relationelle databaser tilbyder fleksibilitet i valget mellem UUID'er, heltal eller hybrider, tager NoSQL-systemer som MongoDB en anden vej.

MongoDB bruger en indbygget type kaldet ObjectId til sit _id felt. Dette er en 12-byte binær værdi, der koder:

• 4 bytes – Tidsstempel (sekunder siden epoke)
• 5 bytes – Tilfældig værdi (ofte baseret på maskine + proces-ID)
• 3 bytes – Inkrementel tæller

Eksempel:

507f1f77bcf86cd799439011

Hvorfor MongoDB vælger ObjectId

1. Globalt unik uden koordination
   Ligesom UUID'er kræver ObjectIds ikke en central myndighed for at sikre unikhed, hvilket gør dem ideelle til distribuerede miljøer.
2. Tidsmæssigt ordnet
   Det indbyggede tidsstempel betyder, at dokumenter er kronologisk ordnede som standard, hvilket kan hjælpe med ydeevnen i tidsserieapplikationer.
3. Kompakt og effektiv
   Lagret i binært format optager ObjectIds kun 12 bytes — meget mindre end en UUID VARCHAR(36). De er også mere venlige over for indeksering.

Sammenligning af ID-strategier

AI-præferencer i NoSQL-kontekster

Mange AI-genererede systemer standardiserer til MongoDB-lignende NoSQL-konfigurationer, når:

• Høj skrivethroughput eller sharding forventes
• Skemaer skal være fleksible eller semi-strukturerede
• Dataportabilitet og distribueret skalering er prioriteter

I sådanne tilfælde er brugen af ObjectIds eller lignende unikke, tidsordenlige identifikatorer ofte et fornuftigt standardvalg.

PrimeCRM