AI și bazele de date MySQL

Este o eroare semnificativă că multe scheme de baze de date generate de AI în prezent au tendința de a folosi VARCHAR(36) pentru coloana id.

Acest lucru este de obicei motivat de dorința de a preveni accesul neautorizat din partea actorilor răuvoitori. Pentru a realiza acest lucru, UUID (Universal Unique Identifiers) sunt adesea folosite ca măsură de securitate.

Să luăm WordPress ca exemplu — acesta dezvăluie în mod obișnuit ID-urile postărilor în URL ca ?p=45. Comparativ cu un format SEO-friendly precum /2025/05/sample-post, acest ID numeric permite utilizatorilor să evalueze potențial și să acceseze conținutul adiacent prin schimbarea numărului (de ex. ?p=44). UUID-urile pe de altă parte nu sunt secvențiale și sunt considerabil mai dificil de ghicit.

UUID-urile sunt șiruri de 36 de caractere care urmează un format standard cu cinci secțiuni separate prin liniuțe: 8-4-4-4-12. Fiecare secțiune constă din valori hexazecimale:

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

Un regex simplu pentru a valida UUID-uri arată astfel:

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

În timp ce UUID-urile oferă securitate și portabilitate, vin cu compromisuri. Ele sunt considerabil mai mari decât numărul întregi, care pot încetini performanța bazei de date — în special când sunt folosite ca chei primare în bazele de date relaționale. Indexarea, utilizarea memoriei și viteza interogărilor toate suferă din cauza mărimii și naturii non-secvențiale a UUID-urilor.

Conversația AI despre strategia ID

Curios despre această alegere de design, am pus această întrebare pentru GitHub Copilot:

Eu:
De ce ai ales să definești coloana id ca VARCHAR(36) PRIMARY KEY în structura bazei de date?

GitHub Copilot:

Am ales VARCHAR(36) pentru coloanele ID din mai multe motive specifice:

1. Stocarea UUID: Lungimea de 36 de caractere se potrivește valorilor UUID, care urmează un format standardizat.
2. Sisteme multi-tenant: UUID-urile ajută la izolarea chiriașilor prin eliminarea scurgerilor de ID secvențiale, simplificând migrațiile și îmbunătățind securitatea.
3. Portabilitatea datelor: UUID-urile asigură că datele exportate nu au conflicte de ID când sunt importate într-un alt sistem.

Compromisuri:

• Dimensiunea de stocare mai mare (36 octeți vs 4 octeți pentru INT)
• Performanța mai lentă de indexare și interogare
• Utilizarea memoriei mai mare

Alternative de luat în considerare:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) pentru a stoca octeții UUID bruti mai eficient
3. Strategie de generare ID personalizată

Anunță-mă dacă preferi o abordare diferită.

Eu:
Folosește BIGINT UNSIGNED pentru performanță, dar păstrează un câmp guid în fiecare înregistrare pentru referințe externe.

GitHub Copilot:

Voi actualiza schema pentru a folosi BIGINT UNSIGNED pentru cheile primare și voi adăuga o coloană guid pentru referințe externe. Această abordare hibridă combină cel mai bun din ambele strategii:

• Performanță: Indexare eficientă și îmbinări prin chei primare numerice
• Securitate și portabilitate: GUID expus în API-uri, menținând ID-urile interne sigure de enumerare

Rezumat:

• BIGINT UNSIGNED: Rapid, compact, secvențial
• GUID (VARCHAR): Unic, portabil, sigur extern

Baze de date NoSQL și MongoDB ObjectIds

În timp ce bazele de date relaționale oferă flexibilitate în alegerea între UUID, numere întregi sau abordări hibride, sistemele NoSQL precum MongoDB iau o cale diferită.

MongoDB folosește un tip încorporat numit ObjectId pentru câmpul său _id. Aceasta este o valoare binară de 12 octeți care codifică:

• 4 octeți – Marcaj temporal (secunde din epoca)
• 5 octeți – Valoare aleatorie (adesea bazată pe mașină + ID proces)
• 3 octeți – Contor incremental

Exemplu:

507f1f77bcf86cd799439011

De ce MongoDB alege ObjectId

1. Unic la nivel global fără coordonare
   La fel ca UUID-urile, ObjectIds nu necesită o autoritate centrală pentru a asigura unicitatea, făcându-le ideale pentru mediile distribuite.
2. Ordonat după timp
   Marcajul temporal încorporat înseamnă că documentele sunt în ordine cronologică în mod implicit, ceea ce poate ajuta performanța în interogările seriilor temporale.
3. Compact și eficient
   Stocate în format binar, ObjectIds ocupă doar 12 octeți — mult mai puțin decât UUID VARCHAR(36). Sunt, de asemenea, mai prietenoase cu indexarea.

Compararea strategiilor ID

Alegeri AI în contexte NoSQL

Multe sisteme generate de AI folosesc configurații NoSQL precum MongoDB în mod implicit când:

• Scrierile înalte sau sharding-ul sunt așteptate
• Schemele trebuie să fie flexibile sau semi-structurate
• Portabilitatea datelor și scalarea distribuită sunt priorități

În astfel de cazuri, este adesea o alegere implicită înțeleaptă să folosești ObjectIds sau identificatori unici similari, ordonați după timp.

PrimeCRM