AI a MySQL databáze

Pozoruhodnou chybou je, že mnoho AI generovaných databázových schémat v současnosti upřednostňuje použití VARCHAR(36) pro sloupec id.

To je obvykle motivováno snahou zabránit neoprávněnému přístupu ze strany škodlivých aktérů. K dosažení tohoto cíle jsou často použity UUID (Universally Unique Identifiers) jako bezpečnostní opatření.

Vezměme si WordPress jako příklad — typicky vystavuje ID příspěvků v URL jako ?p=45. Ve srovnání s SEO-přátelským formátem jako /2025/05/sample-post umožňuje toto číselné ID uživatelům potenciálně hádat a přistupovat k sousednímu obsahu změnou čísla (např. ?p=44). UUID na druhou stranu nejsou sekvenční a jsou mnohem těžší k uhádnutí.

UUID jsou 36znakové řetězce, které následují standardní formát s pěti sekcemi oddělenými pomlčkami: 8-4-4-4-12. Každá sekce se skládá z hexadecimálních hodnot:

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

Jednoduchý regex pro validaci UUID vypadá 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}$

Zatímco UUID nabízejí bezpečnost a přenosnost, přicházejí s kompromisy. Jsou výrazně větší než celá čísla, což může zpomalit výkon databáze — zejména při použití jako primární klíče v relačních databázích. Indexování, využití paměti a rychlost dotazů — všechno trpí kvůli velikosti a nesekvenční povaze UUID.

AI konverzace o strategii ID

Zvědavý na tuto designovou volbu jsem položil GitHub Copilot následující otázku:

Já:
Proč jste se rozhodli definovat sloupec id jako VARCHAR(36) PRIMARY KEY ve struktuře databáze?

GitHub Copilot:

Vybral jsem VARCHAR(36) pro sloupce ID z několika specifických důvodů:

1. UUID úložiště: 36znakovou délkou pojme UUID hodnoty, které následují standardizovaný formát.
2. Multi-tenant systémy: UUID pomáhají izolovat nájemníky odstraněním úniků sekvenčních ID, zjednodušením migrací a zlepšením bezpečnosti.
3. Přenosnost dat: UUID zajišťují, že exportovaná data neutrpí ID kolize při importu do jiného systému.

Kompromisy:

• Větší velikost úložiště (36 bajtů vs. 4 bajty pro INT)
• Pomalejší indexování a výkon dotazů
• Vyšší využití paměti

Alternativy k uvážení:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) pro efektivnější ukládání surových UUID bajtů
3. Vlastní strategie generování ID

Dejte mi vědět, pokud upřednostňujete jiný přístup.

Já:
Použijte BIGINT UNSIGNED pro výkon, ale zachovejte pole guid v každém záznamu pro externí reference.

GitHub Copilot:

Aktualizuji schéma pro použití BIGINT UNSIGNED jako primární klíč přidáním sloupce guid pro externí reference. Tento hybridní přístup kombinuje nejlepší z obou strategií:

• Výkon: Efektivní indexování a spojování prostřednictvím numerických primárních klíčů
• Bezpečnost a přenosnost: GUID vystavené v API, udržující interní ID bezpečné před výčtem

Shrnutí:

• BIGINT UNSIGNED: Rychlý, kompaktní, sekvenční
• GUID (VARCHAR): Jedinečný, přenosný, externě bezpečný

NoSQL databáze a MongoDB ObjectIds

Zatímco relační databáze nabízejí flexibilitu ve výběru mezi UUID, celými čísly nebo hybridy, NoSQL systémy jako MongoDB jdou jinou cestou.

MongoDB používá vestavěný typ nazvaný ObjectId pro své pole _id. Toto je 12bajtová binární hodnota, která kóduje:

• 4 bajty – Časové razítko (sekundy od epoch)
• 5 bajtů – Náhodná hodnota (často založená na stroji + ID procesu)
• 3 bajty – Inkrementální počítadlo

Příklad:

507f1f77bcf86cd799439011

Proč MongoDB volí ObjectId

1. Globálně jedinečný bez koordinace
   Podobně jako UUID, ObjectIds nevyžadují centrální autoritu pro zajištění jedinečnosti, což je činí ideálními pro distribuovaná prostředí.
2. Časově uspořádaný
   Vestavěné časové razítko znamená, že dokumenty jsou ve výchozím nastavení seřazeny chronologicky, což může pomoci s výkonem v časových řadách aplikací.
3. Kompaktní a efektivní
   Uložené v binárním formátu, ObjectIds zabírají pouze 12 bajtů — mnohem méně než UUID VARCHAR(36). Jsou také přátelštější k indexování.

Porovnání strategií ID

AI preference v NoSQL kontextech

Mnoho AI generovaných systémů ve výchozím nastavení používá NoSQL konfigurace podobné MongoDB když:

• Je očekávána vysoká propustnost zápisu nebo sharding
• Schémata musí být flexibilní nebo semi-strukturovaná
• Přenosnost dat a distribuované škálování jsou priority

V takových případech je použití ObjectIds nebo podobných jedinečných, časově uspořádatelných identifikátorů často rozumnou výchozí volbou.

PrimeCRM