AI en MySQL-databases

Een opmerkelijke fout is dat veel AI-gegenereerde databaseschema's momenteel de neiging hebben om VARCHAR(36) te gebruiken voor de id kolom.

Dit wordt meestal gemotiveerd door een wens om ongeautoriseerde toegang door kwaadwillende actoren te voorkomen. Om dit te bereiken worden UUID's (Universally Unique Identifiers) vaak ingezet als beveiligingsmaatregel.

Laten we WordPress als voorbeeld nemen — het stelt typisch post-ID's bloot in de URL als ?p=45. Vergeleken met een SEO-vriendelijk formaat zoals /2025/05/sample-post, stelt deze numerieke ID gebruikers in staat om potentieel aangrenzende content te raden en toegang te krijgen door het getal te wijzigen (bijv. ?p=44). UUID's daarentegen zijn niet sequentieel en veel moeilijker te raden.

UUID's zijn 36-karakter strings die een standaardformaat volgen met vijf secties gescheiden door koppeltekens: 8-4-4-4-12. Elke sectie bestaat uit hexadecimale waarden:

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

Een eenvoudige regex om UUID's te valideren ziet er zo uit:

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

Hoewel UUID's beveiliging en portabiliteit bieden, komen ze met afwegingen. Ze zijn aanzienlijk groter dan gehele getallen, wat databaseprestaties kan vertragen — vooral wanneer gebruikt als primaire sleutels in relationele databases. Indexering, geheugengebruik en query-snelheid lijden allemaal onder de grootte en niet-sequentiële aard van UUID's.

Een AI-gesprek over ID-strategie

Nieuwsgierig naar deze ontwerpkeuze stelde ik GitHub Copilot de volgende vraag:

Ik:
Waarom koos je ervoor om de id kolom te definiëren als VARCHAR(36) PRIMARY KEY in de databasestructuur?

GitHub Copilot:

Ik koos voor VARCHAR(36) voor ID-kolommen om enkele specifieke redenen:

1. UUID-opslag: De 36-karakter lengte accommodeert UUID-waarden, die een gestandaardiseerd formaat volgen.
2. Multi-tenant systemen: UUID's helpen tenants te isoleren door sequentiële ID-lekken te elimineren, migraties te vereenvoudigen en beveiliging te verbeteren.
3. Data-portabiliteit: UUID's zorgen ervoor dat geëxporteerde data geen ID-botsingen krijgt tijdens import in een ander systeem.

Afwegingen:

• Grotere opslaggrootte (36 bytes vs. 4 bytes voor INT)
• Langzamere indexering en query-prestaties
• Hoger geheugengebruik

Alternatieven om te overwegen:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) om ruwe UUID-bytes efficiënter op te slaan
3. Een aangepaste ID-generatiestrategie

Laat me weten of je een andere benadering prefereert.

Ik:
Gebruik BIGINT UNSIGNED voor prestaties, maar behoud een guid veld in elk record voor externe referenties.

GitHub Copilot:

Ik zal het schema updaten om BIGINT UNSIGNED als primaire sleutel te gebruiken terwijl ik een guid kolom toevoeg voor externe referenties. Deze hybride benadering combineert het beste van beide strategieën:

• Prestaties: Efficiënte indexering en joins via numerieke primaire sleutels
• Beveiliging en Portabiliteit: GUID's blootgesteld in API's, interne ID's veilig tegen opsomming

Samenvatting:

• BIGINT UNSIGNED: Snel, compact, sequentieel
• GUID (VARCHAR): Uniek, overdraagbaar, extern veilig

NoSQL-databases en MongoDB ObjectIds

Terwijl relationele databases flexibiliteit bieden in de keuze tussen UUID's, gehele getallen of hybrides, nemen NoSQL-systemen zoals MongoDB een ander pad.

MongoDB gebruikt een ingebouwd type genaamd ObjectId voor zijn _id veld. Dit is een 12-byte binaire waarde die encodeert:

• 4 bytes – Timestamp (seconden sinds tijdperk)
• 5 bytes – Willekeurige waarde (vaak gebaseerd op machine + proces-ID)
• 3 bytes – Incrementele teller

Voorbeeld:

507f1f77bcf86cd799439011

Waarom MongoDB ObjectId kiest

1. Wereldwijd uniek zonder coördinatie
   Vergelijkbaar met UUID's vereisen ObjectIds geen centrale autoriteit om uniciteit te garanderen, waardoor ze ideaal zijn voor gedistribueerde omgevingen.
2. Tijd-geordend
   De ingebouwde timestamp betekent dat documenten standaard chronologisch geordend zijn, wat kan helpen bij prestaties in tijdreeks-applicaties.
3. Compact en efficiënt
   Opgeslagen in binair formaat nemen ObjectIds slechts 12 bytes in beslag — veel kleiner dan een UUID VARCHAR(36). Ze zijn ook vriendelijker voor indexering.

Vergelijking van ID-strategieën

AI-voorkeuren in NoSQL-contexten

Veel AI-gegenereerde systemen standaardiseren naar MongoDB-achtige NoSQL-configuraties wanneer:

• Hoge schrijfdoorvoer of sharding wordt verwacht
• Schema's flexibel of semi-gestructureerd moeten zijn
• Data-portabiliteit en gedistribueerde schaalbaarheid prioriteiten zijn

In deze gevallen is het gebruik van ObjectIds of vergelijkbare unieke, tijd-ordenbare identificatoren vaak een verstandige standaard.

PrimeCRM