AI ir MySQL duomenų bazės

Tai yra reikšminga klaida, kad daugelis AI generuojamų duomenų bazių schemų šiuo metu yra linkę naudoti VARCHAR(36) stulpeliui id.

Tai paprastai skatina noras užkirsti kelią neteisėtai prieigai iš kenkėjiškų dalyvių. Siekiant tai pasiekti, UUID (universalūs unikalūs identifikatoriai) dažnai naudojami kaip saugumo priemonė.

Imkime WordPress kaip pavyzdį — jis paprastai atskleidžia įrašų ID URL kaip ?p=45. Palyginti su SEO draugišku formatu kaip /2025/05/sample-post, šis skaitinis ID leidžia naudotojams galbūt įvertinti ir pasiekti gretimą turinį keičiant skaičių (pvz., ?p=44). UUID kita vertus nėra nuoseklūs ir gerokai sunkesni spėti.

UUID yra 36 simbolių eilutės, kurios atitinka standartinį formatą su penkiais skyriais, atskirti brūkšneliais: 8-4-4-4-12. Kiekvienas skyrius susideda iš šešioliktainių reikšmių:

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

Paprastas regex UUID patvirtinimui atrodo taip:

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

Nors UUID teikia saugumą ir perkeliamumą, jie ateina su kompromisais. Jie yra žymiai didesni nei sveikieji skaičiai, kas gali sulėtinti duomenų bazės našumą — ypač kai naudojami kaip pirminiai raktai reliacinėse duomenų bazėse. Indeksavimas, atminties naudojimas ir užklausų greitis visi kenčia dėl UUID dydžio ir ne nuoseklaus pobūdžio.

AI pokalbis apie ID strategiją

Smalsi dėl šio dizaino pasirinkimo, pateikiau šį klausimą GitHub Copilot:

Aš:
Kodėl pasirinkote apibrėžti id stulpelį kaip VARCHAR(36) PRIMARY KEY duomenų bazės struktūroje?

GitHub Copilot:

Pasirinkau VARCHAR(36) ID stulpeliams dėl kelių specifinių priežasčių:

1. UUID saugojimas: 36 simbolių ilgis tinka UUID reikšmėms, kurios atitinka standartizuotą formatą.
2. Daugianuomininko sistemos: UUID padeda izoliuoti nuomininkus eliminuojant nuoseklių ID nutekėjimą, supaprastinant migracijas ir gerinant saugumą.
3. Duomenų perkeliamumas: UUID užtikrina, kad eksportuoti duomenys neturi ID konfliktų importuojant į kitą sistemą.

Kompromisai:

• Didesnis saugojimo dydis (36 baitai prieš 4 baitus INT)
• Lėtesnis indeksavimo ir užklausų našumas
• Didesnė atminties naudojimas

Alternatyvos svarstyti:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) saugoti neapdirbtiems UUID baitams efektyviau
3. Pasirinktinė ID generavimo strategija

Duokite man žinoti, jei pageidiaukite kito požiūrio.

Aš:
Naudokite BIGINT UNSIGNED našumui, bet išlaikykite guid lauką kiekviename įraše išorės nuorodoms.

GitHub Copilot:

Atnaujinsiu schemą naudoti BIGINT UNSIGNED pirminiams raktams ir pridėti guid stulpelį išorės nuorodoms. Šis hibridinis požiūris sujungia geriausią iš abiejų strategijų:

• Našumas: Efektyvus indeksavimas ir sujungimai per skaitinius pirminius raktus
• Saugumas ir perkeliamumas: GUID atskleis API, palaikant vidinius ID saugius nuo enumeracijos

Santrauka:

• BIGINT UNSIGNED: Greitas, kompaktiškas, nuoseklus
• GUID (VARCHAR): Unikalus, perkeliamas, saugus išoriškai

NoSQL duomenų bazės ir MongoDB ObjectIds

Nors reliacinės duomenų bazės siūlo lankstumą renkantis tarp UUID, sveikųjų skaičių ar hibridinių požiūrių, NoSQL sistemos kaip MongoDB pasirenka kitą kelią.

MongoDB naudoja įtaisytą tipą vadinamą ObjectId savo _id laukui. Tai yra 12-baitų dvejetainė reikšmė, kuri koduoja:

• 4 baitai – Laiko žyma (sekundės nuo epochos)
• 5 baitai – Atsitiktinė reikšmė (dažnai remiantis mašina + proceso ID)
• 3 baitai – Didėjantis skaitiklis

Pavyzdys:

507f1f77bcf86cd799439011

Kodėl MongoDB renkasi ObjectId

1. Globaliai unikalus be koordinacijos
   Kaip ir UUID, ObjectIds nereikalauja centrinio valdžios unikalumui užtikrinti, todėl jie idealūs paskirstytoms aplinkoms.
2. Laiku surūšiuoti
   Įtaisytas laiko žymas reiškia, kad dokumentai yra chronologine tvarka pagal nutylėjimą, kas gali padėti našumui laiko serijų užklausose.
3. Kompaktiškas ir efektyvus
   Saugomi dvejetainiame formate, ObjectIds užima tik 12 baitų — gerokai mažiau nei UUID VARCHAR(36). Jie taip pat draugiškesni indeksavimui.

ID strategijų palyginimas

AI sprendimai NoSQL kontekstuose

Daug AI generuojamų sistemų naudoja NoSQL konfigūracijas kaip MongoDB pagal nutylėjimą, kai:

• Tikimasi aukšto rašymo arba sharding
• Schemos turi būti lankstūs arba pusiau struktūrizuoti
• Duomenų perkeliamumas ir paskirstytas mastelis yra prioritetas

Tokiais atvejais dažnai protingas nutylėjimo pasirinkimas yra naudoti ObjectIds arba panašius unikalius, laiku surūšiuotus identifikatorius.

PrimeCRM