AI i MySQL baze podataka

Uočljiva greška je da mnoge AI generirane sheme baze podataka trenutno preferiraju korištenje VARCHAR(36) za kolonu id.

Ovo je obično motivisano željom da se spriječi neovlašten pristup od zlonamjernih aktera. Da bi se to postiglo, UUID-jevi (Universally Unique Identifiers) se često koriste kao sigurnosna mjera.

Uzmimo WordPress kao primjer — tipično izlaže ID-jeve objava u URL-u kao ?p=45. U usporedbi s SEO-prijateljskim formatom poput /2025/05/sample-post, ovaj numerički ID omogućava korisnicima da potencijalno pogode i pristupe susjednom sadržaju mijenjanjem broja (npr. ?p=44). UUID-jevi s druge strane nisu sekvencijalni i mnogo su teži za pogađanje.

UUID-jevi su stringovi od 36 znakova koji slijede standardni format s pet sekcija razdvojenih crticama: 8-4-4-4-12. Svaka sekcija se sastoji od heksadecimalnih vrijednosti:

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

Jednostavan regex za validaciju UUID-jeva izgleda ovako:

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

Dok UUID-jevi pružaju sigurnost i prenosivost, dolaze s kompromisima. Značajno su veći od cijelih brojeva, što može usporavati performanse baze podataka — posebno kada se koriste kao primarni ključevi u relacijskim bazama podataka. Indeksiranje, korištenje memorije i brzina upita — sve pati zbog veličine i nesekvencijalne prirode UUID-jeva.

AI razgovor o ID strategiji

Zainteresiran ovim izbором dizajna, postavio sam GitHub Copilotu sljedeće pitanje:

Ja:
Zašto ste odabrali definirati kolonu id kao VARCHAR(36) PRIMARY KEY u strukturi baze podataka?

GitHub Copilot:

Odabrao sam VARCHAR(36) za ID kolone iz nekoliko specifičnih razloga:

1. UUID skladištenje: Duljina od 36 znakova prihvaća UUID vrijednosti koje slijede standardizirani format.
2. Multi-tenant sustavi: UUID-jevi pomažu izolirati stanare eliminiranjem sekvencijalnih ID curenja, pojednostavljujući migracije i poboljšavajući sigurnost.
3. Prenosivost podataka: UUID-jevi osiguravaju da izvezeni podaci neće doživjeti ID kolizije prilikom uvoza u drugi sustav.

Kompromisi:

• Veća veličina skladištenja (36 bajtova vs. 4 bajta za INT)
• Sporije indeksiranje i performanse upita
• Veće korištenje memorije

Alternative za razmotriti:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) za efikasniju pohranu sirovih UUID bajtova
3. Prilagođena strategija generiranja ID-a

Javite mi ako preferirate drugačiji pristup.

Ja:
Koristite BIGINT UNSIGNED za performanse, ali zadržite polje guid u svakom zapisu za vanjske reference.

GitHub Copilot:

Ažurirat ću shemu da koristi BIGINT UNSIGNED kao primarni ključ dodavanjem kolone guid za vanjske reference. Ovaj hibridni pristup kombinira najbolje od obje strategije:

• Performanse: Efikasno indeksiranje i spajanja kroz numeričke primarne ključeve
• Sigurnost i prenosivost: GUID-jevi izloženi u API-jima, održavaju interne ID-jeve sigurnima od nabrajanja

Sažetak:

• BIGINT UNSIGNED: Brz, kompaktan, sekvencijalan
• GUID (VARCHAR): Jedinstven, prenosiv, eksterno siguran

NoSQL baze podataka i MongoDB ObjectId-jevi

Dok relacijske baze podataka pružaju fleksibilnost u odabiru između UUID-jeva, cijelih brojeva ili hibrida, NoSQL sustavi poput MongoDB-a uzimaju drugačiji put.

MongoDB koristi ugrađeni tip nazvan ObjectId za svoje _id polje. Ovo je 12-bajtna binarna vrijednost koja kodira:

• 4 bajta – Vremenska oznaka (sekunde od epohe)
• 5 bajtova – Nasumična vrijednost (često bazirana na stroju + ID procesa)
• 3 bajta – Incrementalni brojač

Primjer:

507f1f77bcf86cd799439011

Zašto MongoDB odabira ObjectId

1. Globalno jedinstven bez koordinacije
   Slično UUID-jevima, ObjectId-jevi ne zahtijevaju centralni autoritet za osiguravanje jedinstvenosti, čineći ih idealnima za distribuirane okoline.
2. Vremenski uređen
   Ugrađena vremenska oznaka znači da su dokumenti kronološki uređeni po defaultu, što može pomoći s performansama u time-series aplikacijama.
3. Kompaktan i efikasan
   Pohranjeni u binarnom formatu, ObjectId-jevi zauzimaju samo 12 bajtova — mnogo manje od UUID VARCHAR(36). Također su prijateljski za indeksiranje.

Usporedba ID strategija

AI preferencije u NoSQL kontekstima

Mnogi AI generirani sustavi defaultno koriste MongoDB-slične NoSQL konfiguracije kada:

• Se očekuje visoki write throughput ili sharding
• Sheme trebaju biti fleksibilne ili polu-strukturirane
• Prenosivost podataka i distribuirano skaliranje su prioriteti

U takvim slučajevima, korištenje ObjectId-jeva ili sličnih jedinstvenih, vremenski uređenih identifikatora često je razuman default izbor.

PrimeCRM