AI a MySQL databázy

Je to významná chyba, že mnohé AI generované databázové schémy v súčasnosti majú tendenciu používať VARCHAR(36) pre stĺpec id.

Toto je zvyčajne motivované túžbou zabrániť neoprávnenému prístupu od škodlivých aktérov. Na dosiahnutie tohto sa UUID (Universal Unique Identifiers) často používajú ako bezpečnostné opatrenie.

Vezmime si WordPress ako príklad — obvykle odhaľuje ID príspevkov v URL ako ?p=45. V porovnaní s SEO-priateľským formátom ako /2025/05/sample-post, toto numerické ID umožňuje používateľom potenciálne vyhodnotiť a pristupovať k susednému obsahu zmenou čísla (napr. ?p=44). UUID sú na druhej strane nesekvenčné a podstatne ťažšie uhádnuť.

UUID sú 36-znakové reťazce, ktoré nasledujú štandardný formát s piatimi sekciami oddelenými pomlčkami: 8-4-4-4-12. Každá sekcia sa skladá z hexadecimálnych hodnôt:

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

Jednoduchý regex na validáciu UUID vyzerá takto:

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

Zatiaľ čo UUID poskytujú bezpečnosť a prenosnosť, prichádzajú s kompromismi. Sú podstatne väčšie ako celé čísla, čo môže spomaliť výkon databázy — najmä pri použití ako primárne kľúče v relačných databázach. Indexovanie, využitie pamäte a rýchlosť dotazov všetko trpí kvôli veľkosti a nesekvenčnej povahe UUID.

AI rozhovor o ID stratégii

Zvedavý na túto dizajnérsku voľbu som položil túto otázku GitHub Copilot:

Ja:
Prečo si sa rozhodol definovať stĺpec id ako VARCHAR(36) PRIMARY KEY v databázovej štruktúre?

GitHub Copilot:

Zvolil som VARCHAR(36) pre ID stĺpce z niekoľkých konkrétnych dôvodov:

1. UUID úložisko: 36-znakový rozsah vyhovuje UUID hodnotám, ktoré nasledujú štandardizovaný formát.
2. Viacnájomné systémy: UUID pomáhajú izolovať nájomníkov eliminovaním sekvenčných ID úniky, zjednodušovaním migrácií a zlepšovaním bezpečnosti.
3. Prenosnosť dát: UUID zabezpečujú, že exportované dáta nemajú ID konflikty pri importovaní do iného systému.

Kompromisy:

• Väčšia veľkosť úložiska (36 bajtov vs 4 bajty pre INT)
• Pomalší výkon indexovania a dotazovania
• Vyššie využitie pamäte

Alternatívy na zváženie:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) na uloženie surových UUID bajtov efektívnejšie
3. Vlastná stratégia generovania ID

Daj mi vedieť, ak by si uprednostnil iný prístup.

Ja:
Použij BIGINT UNSIGNED pre výkon, ale ponechaj pole guid v každom zázname pre externé referencie.

GitHub Copilot:

Aktualizujem schému na použitie BIGINT UNSIGNED pre primárne kľúče a pridám stĺpec guid pre externé referencie. Tento hybridný prístup kombinuje to najlepšie z oboch stratégií:

• Výkon: Efektívne indexovanie a spájanie cez numerické primárne kľúče
• Bezpečnosť a prenosnosť: GUID exponované v API, udržanie vnútorných ID bezpečných od enumerácie

Súhrn:

• BIGINT UNSIGNED: Rýchly, kompaktný, sekvenčný
• GUID (VARCHAR): Unikátny, prenosný, externe bezpečný

NoSQL databázy a MongoDB ObjectIds

Zatiaľ čo relačné databázy ponúkajú flexibilitu vo výbere medzi UUID, celými číslami alebo hybridnými prístupmi, NoSQL systémy ako MongoDB idú inou cestou.

MongoDB používa zabudovaný typ nazývaný ObjectId pre svoje pole _id. Toto je 12-bajtová binárna hodnota, ktorá kóduje:

• 4 bajty – Časová značka (sekundy od epochy)
• 5 bajtov – Náhodná hodnota (často založená na stroji + ID procesu)
• 3 bajty – Inkrementálny počítadlo

Príklad:

507f1f77bcf86cd799439011

Prečo MongoDB volí ObjectId

1. Globálne unikátne bez koordinácie
   Ako UUID, ObjectIds nevyžadujú centrálnu autoritu na zabezpečenie jedinečnosti, čo ich robí ideálnymi pre distribuované prostredia.
2. Časovo usporiadané
   Zabudovaná časová značka znamená, že dokumenty sú v chronologickom poradí predvolene, čo môže pomôcť výkonu v dotazoch časových radov.
3. Kompaktné a efektívne
   Uložené v binárnom formáte, ObjectIds zaberajú len 12 bajtov — omnoho menej ako UUID VARCHAR(36). Sú tiež priateľskejšie k indexovaniu.

Porovnanie ID stratégií

AI výbery v NoSQL kontextoch

Mnohé AI generované systémy používajú NoSQL konfigurácie ako MongoDB predvolene, keď:

• Sú očakávané vysoké zápisy alebo sharding
• Schémy musia byť flexibilné alebo pološtruktúrované
• Prenosnosť dát a distribuované škálovanie sú priority

V takýchto prípadoch je často múdrou predvolenou voľbou použiť ObjectIds alebo podobné unikátne, časovo usporiadané identifikátory.

PrimeCRM