AI ja MySQL andmebaasid

Märkimisväärne viga on see, et paljud AI poolt loodud andmebaasiskeem eelistavad praegu VARCHAR(36) kasutamist id veeru jaoks.

See on tavaliselt motiveeritud soovist vältida volitamata juurdepääsu pahatahtlike tegijate poolt. Selle saavutamiseks kasutatakse sageli UUID-sid (Universally Unique Identifiers) turvameetmena.

Võtame näiteks WordPressi — see tavaliselt paljastab postituse ID-d URL-is kui ?p=45. Võrreldes SEO-sõbraliku vorminguga nagu /2025/05/sample-post, võimaldab see numbriline ID kasutajatel potentsiaalselt ära arvata ja pääseda ligi külgnevale sisule numbri muutmisega (nt ?p=44). UUID-d teisest küljest ei ole järjestikusud ja on palju raskemini äraarvatavad.

UUID-d on 36-märgilised stringid, mis järgivad standardset vormigu viie kriipsuga eraldatud sektsiooniga: 8-4-4-4-12. Iga sektsioon koosneb kuueteistkümnendväärtustest:

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

Lihtne regex UUID-de valideerimiseks näeb välja selline:

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

Kuigi UUID-d pakuvad turvalisust ja kaasaskantavust, tulevad need kompromissidega. Need on märgatavalt suuremad kui täisarvud, mis võib aeglustada andmebaasi jõudlust — eriti kui neid kasutatakse peamiste võtmetena relatsionaalsetes andmebaasides. Indekseerimine, mälukasutus ja päringu kiirus kannatavad kõik UUID-de suuruse ja mittejärjestikuse loomuse tõttu.

AI vestlus ID-strateegia kohta

Selle disainivaliku peale uudishimulik, esitasin GitHub Copilot'le järgmise küsimuse:

Mina:
Miks valisite id veeru määratlemise VARCHAR(36) PRIMARY KEY kui andmebaasi struktuuris?

GitHub Copilot:

Valisin VARCHAR(36) ID veergudele mitme konkreetse põhjuse tõttu:

1. UUID salvestamine: 36-märgiline pikkus mahutab UUID väärtused, mis järgivad standardiseeritud vormigu.
2. Mitmekliendisüsteemid: UUID-d aitavad isoleerida kliente, kõrvaldades järjestikuseid ID lekkeid, lihtsustades migratsioone ja parandades turvalisust.
3. Andmete kaasaskantavus: UUID-d tagavad, et eksporditud andmed ei koge ID kokkupõrkeid teise süsteemi importimisel.

Kompromissid:

• Suurem salvestusmaht (36 baiti vs. 4 baiti INT jaoks)
• Aeglasem indekseerimise ja päringu jõudlus
• Suurem mälukasutus

Kaaluda olevad alternatiivid:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) tõhusamaks toore UUID baitide salvestamiseks
3. Kohandatud ID genereerimise strateegia

Andke teada, kui eelistate teistsugust lähenemist.

Mina:
Kasutage BIGINT UNSIGNED jõudluse jaoks, kuid hoidke guid väli igas kirjes väliste viidete jaoks.

GitHub Copilot:

Uuendan skeemi kasutamaks BIGINT UNSIGNED peamise võtmena, lisades guid veeru väliste viidete jaoks. See hübriidne lähenemine ühendab mõlema strateegia parima:

• Jõudlus: Tõhus indekseerimine ja liitmised numbriliste peamiste võtmete kaudu
• Turvalisus ja kaasaskantavus: GUID-d paljastatud API-des, hoides sisemised ID-d turvalisena loendamise eest

Kokkuvõte:

• BIGINT UNSIGNED: Kiire, kompaktne, järjestikune
• GUID (VARCHAR): Unikaalne, kaasaskantav, väliselt turvaline

NoSQL andmebaasid ja MongoDB ObjectIds

Kuigi relatsionaalsed andmebaasid pakuvad paindlikkust UUID-de, täisarvude või hübriidide vahel valides, võtavad NoSQL süsteemid nagu MongoDB teistsuguse tee.

MongoDB kasutab sisseehitatud tüüpi nimega ObjectId oma _id välja jaoks. See on 12-baidine binaarvaartus, mis kodeerib:

• 4 baiti – Ajatempel (sekundid epohhi ajast)
• 5 baiti – Juhuslik väärtus (sageli masina + protsessi ID põhjal)
• 3 baiti – Suurenev loendur

Näide:

507f1f77bcf86cd799439011

Miks MongoDB valib ObjectId

1. Globaalselt unikaalne ilma koordinatsioonita
   Sarnaselt UUID-dele ei nõua ObjectIds keskset autoriteeti unikaalsuse tagamiseks, muutes need ideaalseks hajutatud keskkondades.
2. Ajas järjestatud
   Sisseehitatud ajatempel tähendab, et dokumendid on vaikimisi kronoloogiliselt järjestatud, mis võib aidata jõudlust ajaseeria rakendustes.
3. Kompaktne ja tõhus
   Binaarformaadis salvestatud ObjectIds võtavad ainult 12 baiti — palju vähem kui UUID VARCHAR(36). Need on ka indekseerimissõbralikumad.

ID strateegiate võrdlus

AI eelistused NoSQL kontekstides

Paljud AI poolt genereeritud süsteemid vaikimisi kasutavad MongoDB-taolisi NoSQL konfiguratsioone, kui:

• Oodatakse kõrget kirjutamise läbilaskevõimet või sharding'ut
• Skeemid peavad olema paindlikud või pool-struktureeritud
• Andmete kaasaskantavus ja hajutatud skaleerimine on prioriteedid

Sellistel juhtudel on ObjectIds või sarnaste unikaalsete, ajas järjestatavate identifikaatorite kasutamine sageli mõistlik vaikimisi valik.

PrimeCRM