AI in MySQL podatkovne baze

To je pomembna napaka, da mnoge AI generirane podatkovne sheme trenutno težijo k uporabi VARCHAR(36) za stolpec id.

To je običajno motivirano z željo preprečiti nepooblaščen dostop s strani zlonamernih akterjev. Za dosego tega se UUID (Universal Unique Identifiers) pogosto uporabljajo kot varnostni ukrep.

Vzemimo WordPress kot primer — običajno razkrije ID-je objav v URL-ju kot ?p=45. V primerjavi s SEO-prijaznim formatom kot /2025/05/sample-post, ta numerični ID omogoča uporabnikom potencialno oceniti in dostopati do sosednje vsebine s spreminjanjem števila (npr. ?p=44). UUID so po drugi strani nesekvenčni in bistveno težji za ugibanje.

UUID so 36-znakovi nizi, ki sledijo standardnemu formatu s petimi odseki, ločenimi s črtice: 8-4-4-4-12. Vsak odsek sestavlja heksadecimalne vrednosti:

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

Preprost regex za validacijo UUID-jev izgleda tako:

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

Čeprav UUID-ji zagotavljajo varnost in prenosljivost, prihajajo s kompromisi. Bistveno večji so od celih števil, kar lahko upočasni zmogljivost podatkovne baze — posebej pri uporabi kot primarni ključi v relacijskih podatkovnih bazah. Indeksiranje, uporaba pomnilnika in hitrost poizvedb vse trpi zaradi velikosti in nesekvenčne narave UUID-jev.

AI pogovor o ID strategiji

Radoveden o tej oblikovalski izbiri sem postavil to vprašanje GitHub Copilot:

Jaz:
Zakaj si se odločil definirati stolpec id kot VARCHAR(36) PRIMARY KEY v strukturi podatkovne baze?

GitHub Copilot:

Izbral sem VARCHAR(36) za ID stolpce iz več specifičnih razlogov:

1. UUID shranjevanje: 36-znakovna dolžina ustreza UUID vrednostim, ki sledijo standardiziranemu formatu.
2. Večnajemniški sistemi: UUID pomagajo izolirati najemnike z odpravo sekvenčnih ID uhajanj, poenostavljanjem migracij in izboljšanjem varnosti.
3. Prenosljivost podatkov: UUID zagotavljajo, da izvoženi podatki nimajo ID konfliktov pri uvozu v drugi sistem.

Kompromisi:

• Večja velikost shranjevanja (36 bajtov proti 4 bajtom za INT)
• Počasnejša zmogljivost indeksiranja in poizvedovanja
• Višja uporaba pomnilnika

Alternativi za premislek:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) za shranjevanje surovih UUID bajtov bolj učinkovito
3. Prilagojena strategija generiranja ID

Sporoči mi, če bi raje drugačen pristop.

Jaz:
Uporabi BIGINT UNSIGNED za zmogljivost, vendar ohrani polje guid v vsakem zapisu za zunanje reference.

GitHub Copilot:

Posodobil bom shemo, da bo uporabljala BIGINT UNSIGNED za primarne ključe in dodal stolpec guid za zunanje reference. Ta hibridni pristop združuje najboljše iz obeh strategij:

• Zmogljivost: Učinkovito indeksiranje in spajanje preko numeričnih primarnih ključev
• Varnost in prenosljivost: GUID izpostavljeni v API-jih, ohranjajo notranje ID-je varne pred naštevanjem

Povzetek:

• BIGINT UNSIGNED: Hiter, kompakten, sekvencijski
• GUID (VARCHAR): Edinstven, prenosljiv, zunanje varen

NoSQL podatkovne baze in MongoDB ObjectIds

Medtem ko relacijske podatkovne baze ponujajo fleksibilnost pri izbiri med UUID, celimi števili ali hibridnimi pristopi, NoSQL sistemi kot MongoDB gredo po drugačni poti.

MongoDB uporablja vgrajeno vrsto, imenovano ObjectId za svoje polje _id. To je 12-bajtni binarni zapis, ki kodira:

• 4 bajti – Časovni žig (sekunde od epohe)
• 5 bajtov – Naključna vrednost (pogosto na osnovi stroja + ID procesa)
• 3 bajti – Naraščajoči števec

Primer:

507f1f77bcf86cd799439011

Zakaj MongoDB izbere ObjectId

1. Globalno edinstven brez koordinacije
   Kot UUID, ObjectIds ne potrebujejo centralne avtoritete za zagotovitev edinstvenosti, kar jih naredi idealne za distribuirana okolja.
2. Časovno urejeno
   Vgrajeni časovni žig pomeni, da so dokumenti v kronološkem vrstnem redu privzeto, kar lahko pomaga zmogljivosti pri poizvedbah časovnih vrst.
3. Kompaktno in učinkovito
   Shranjeni v binarnem formatu, ObjectIds zavzamejo le 12 bajtov — veliko manj kot UUID VARCHAR(36). So tudi bolj prijazni za indeksiranje.

Primerjava ID strategij

AI izbire v NoSQL kontekstih

Mnogi AI generirani sistemi uporabljajo NoSQL konfiguracije kot MongoDB privzeto, ko:

• Pričakovani so visoki vpisi ali sharding
• Sheme morajo biti fleksibilne ali polstrukturirane
• Prenosljivost podatkov in distribuirano skaliranje so prioritete

V takšnih primerih je pogosto modra privzeta izbira uporabiti ObjectIds ali podobne edinstvene, časovno urejene identifikatorje.

PrimeCRM