AI és MySQL adatbázisok

Egy figyelemre méltó hiba, hogy sok AI által generált adatbázis séma jelenleg a VARCHAR(36) használatát részesíti előnyben az id oszlophoz.

Ez általában egy rosszindulatú szereplők általi jogosulatlan hozzáférés megakadályozásának vágyától motivált. Ennek elérése érdekében az UUID-ket (Universally Unique Identifiers) gyakran biztonsági intézkedésként alkalmazzák.

Vegyük például a WordPress-t — általában úgy teszi közzé a bejegyzés ID-kat az URL-ben, mint ?p=45. Egy SEO-barát formátummal összehasonlítva, mint /2025/05/sample-post, ez a numerikus ID lehetővé teszi a felhasználók számára, hogy potenciálisan kitalálják és hozzáférjenek a szomszédos tartalomhoz a szám módosításával (pl. ?p=44). Az UUID-k viszont nem szekvenciálisak és sokkal nehezebben kitalálhatóak.

Az UUID-k 36 karakteres sztringek, amelyek szabványos formátumot követnek öt kötőjellel elválasztott részlegben: 8-4-4-4-12. Minden rész hexadecimális értékekből áll:

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

Egy egyszerű regex az UUID-k validálására így néz ki:

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

Míg az UUID-k biztonságot és hordozhatóságot kínálnak, kompromisszumokkal járnak. Jelentősen nagyobbak az egész számoknál, ami lelassíthatja az adatbázis teljesítményét — különösen amikor elsődleges kulcsként használják relációs adatbázisokban. Az indexelés, memóriahasználat és lekérdezési sebesség mind szenved az UUID-k mérete és nem-szekvenciális természete miatt.

Egy AI beszélgetés az ID stratégiáról

Kíváncsi voltam erre a tervezési választásra, ezért feltetettem a következő kérdést a GitHub Copilot-nak:

Én:
Miért döntöttél úgy, hogy az id oszlopot VARCHAR(36) PRIMARY KEY-ként definiálod az adatbázis struktúrában?

GitHub Copilot:

A VARCHAR(36)-ot választottam az ID oszlopokhoz több konkrét okból:

1. UUID tárolás: A 36 karakteres hossz befogadja az UUID értékeket, amelyek szabványosított formátumot követnek.
2. Több-bérlős rendszerek: Az UUID-k segítenek elkülöníteni a bérlőket a szekvenciális ID szivárgások kiküszöbölésével, egyszerűsítve a migrációkat és javítva a biztonságot.
3. Adat hordozhatóság: Az UUID-k biztosítják, hogy az exportált adatok ne szenvedjenek ID ütközéseket más rendszerbe való importáláskor.

Kompromisszumok:

• Nagyobb tárolási méret (36 byte vs. 4 byte az INT-hez képest)
• Lassabb indexelési és lekérdezési teljesítmény
• Magasabb memóriahasználat

Mérlegelhető alternatívák:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) a nyers UUID byte-ok hatékonyabb tárolásához
3. Egyéni ID generálási stratégia

Szólj, ha más megközelítést preferálnál.

Én:
Használj BIGINT UNSIGNED-ot a teljesítményért, de tarts meg egy guid mezőt minden rekordban külső hivatkozásokhoz.

GitHub Copilot:

Frissítem a sémát, hogy BIGINT UNSIGNED-ot használjon elsődleges kulcsként, miközben hozzáadok egy guid oszlopot külső hivatkozásokhoz. Ez a hibrid megközelítés kombinálja mindkét stratégia legjavát:

• Teljesítmény: Hatékony indexelés és join-ok numerikus elsődleges kulcsokon keresztül
• Biztonság és hordozhatóság: GUID-ok közzétéve az API-kban, a belső ID-k biztonságban maradnak a felsorolástól

Összefoglaló:

• BIGINT UNSIGNED: Gyors, kompakt, szekvenciális
• GUID (VARCHAR): Egyedi, hordozható, kívülről biztonságos

NoSQL adatbázisok és MongoDB ObjectIds

Míg a relációs adatbázisok rugalmasságot kínálnak az UUID-k, egész számok vagy hibridek közötti választásban, a NoSQL rendszerek, mint a MongoDB más utat választanak.

A MongoDB egy beépített típust használ, amelyet ObjectId-nek hívnak az _id mezőjéhez. Ez egy 12 bájtos bináris érték, amely kódol:

• 4 bájt – Időbélyeg (másodpercek az epocha óta)
• 5 bájt – Véletlenszerű érték (gyakran gép + folyamat ID alapú)
• 3 bájt – Növekményes számláló

Példa:

507f1f77bcf86cd799439011

Miért választja a MongoDB az ObjectId-t

1. Globálisan egyedi koordináció nélkül
   Az UUID-khoz hasonlóan az ObjectIds nem igényel központi hatóságot az egyediség biztosításához, ideálissá téve őket elosztott környezetekhez.
2. Időben rendezett
   A beépített időbélyeg azt jelenti, hogy a dokumentumok alapértelmezetten kronológiailag rendezettek, ami segíthet a teljesítményben idősorozat alkalmazásokban.
3. Kompakt és hatékony
   Bináris formátumban tárolva az ObjectIds csak 12 bájtot foglalnak el — sokkal kisebb, mint egy UUID VARCHAR(36). Indexelés-barátabbak is.

ID stratégiák összehasonlítása

AI preferenciák NoSQL kontextusokban

Sok AI által generált rendszer alapértelmezetten MongoDB-szerű NoSQL konfigurációkat használ, amikor:

• Magas írási áteresztőképesség vagy sharding várható
• A sémáknak rugalmasnak vagy félig strukturáltnak kell lenniük
• Az adat hordozhatóság és elosztott skálázás prioritások

Ilyen esetekben az ObjectIds vagy hasonló egyedi, időben rendezhető azonosítók használata gyakran ésszerű alapértelmezett választás.

PrimeCRM