AI un MySQL datu bāzes

Tas ir nozīmīga kļūda, ka daudzi AI ģenerēti datu bāzu shēmu pašlaik ir noslieci izmantot VARCHAR(36) par id kolonnai.

Tas parasti tiek mudināts ar vēlmi nepieļaut neatļautu piekļuvi no ļaunprātīgiem dalībniekiem. Lai to panāktu, UUID (Universālie unikālie identifikatori) bieži tiek izmantoti kā drošības pasākums.

Ņemsim WordPress kā piemēru — tas parasti atklāj ierakstu ID URL kā ?p=45. Salīdzinot ar SEO draudzīgu formātu kā /2025/05/sample-post, šis skaitliskais ID ļauj lietotājiem iespējams novērtēt un piekļūt blakus esošajam saturam, mainot skaitli (piem., ?p=44). UUID savukārt nav secīgi un ir ievērojami grūtāk uzminēt.

UUID ir 36 rakstzīmju virknes, kas atbilst standarta formātam ar piecām sadaļām, atdalītām ar defisēm: 8-4-4-4-12. Katra sadaļa sastāv no heksadecimālām vērtībām:

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

Vienkāršs regex UUID validācijai izskatās šādi:

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

Lai gan UUID nodrošina drošību un pārnesamību, tie nāk ar kompromisiem. Tie ir ievērojami lielāki nekā veseli skaitļi, kas varētu palēnināt datu bāzes veiktspēju — īpaši izmantojot tos kā primārās atslēgas relāciju datu bāzēs. Indeksēšana, atmiņas izmantošana un vaicājumu ātrums viss cieš no UUID izmēra un ne-secīgā rakstura.

AI saruna par ID stratēģiju

Zinotkārīgs par šo dizaina izvēli, es uzdodu šo jautājumu GitHub Copilot:

Es:
Kādēļ jūs izvēlējāties definēt id kolonnu kā VARCHAR(36) PRIMARY KEY datu bāzes struktūrā?

GitHub Copilot:

Es izvēlējos VARCHAR(36) ID kolonnām vairāku konkrētu iemeslu dēļ:

1. UUID uzglabāšana: 36 rakstzīmju garums atbilst UUID vērtībām, kas seko standartizētajam formātam.
2. Daudznomnieku sistēmas: UUID palīdz izolēt nomniekiem, eliminējot secīgo ID noplūdi, vienkāršojot migrācijas un uzlabojot drošību.
3. Datu pārnesamība: UUID nodrošina, ka eksportētajiem datiem nav ID konfliktu, importējot tos citā sistēmā.

Kompromisi:

• Lielāks uzglabāšanas izmērs (36 baiti pret 4 baitiem INT)
• Lēnāka indeksēšana un vaicājumu veiktspēja
• Augstāka atmiņas izmantošana

Alternatīvas apsvērt:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) uzglabāt neapstrādātus UUID baitus efektīvāk
3. Pielāgota ID ģenerēšanas stratēģija

Lūdzu, ļaujiet man zināt, ja jūs labprāt redzētu citu pieeju.

Es:
Izmantojiet BIGINT UNSIGNED veiktspējam, bet saglabājiet guid lauku katrā ierakstā ārējām atsaucēm.

GitHub Copilot:

Es atjaunošu shēmu, lai izmantotu BIGINT UNSIGNED primārajām atslēgām un pievienotu guid kolonnu ārējām atsaucēm. Šī hibrīdā pieeja apvieno labāko no abām stratēģijām:

• Veiktspēja: Efektīva indeksēšana un savienošana ar skaitliskajiem primārajiem atslēgām
• Drošība un pārnesamība: GUID atklāti API, saglabājot iekšējās ID drošas no uzskaitīšanas

Kopsavilkums:

• BIGINT UNSIGNED: Ātrs, kompakts, secīgs
• GUID (VARCHAR): Unikāls, pārnesams, ārēji drošs

NoSQL datu bāzes un MongoDB ObjectIds

Kamēr relāciju datu bāzes piedāvā elastību izvēloties starp UUID, veseliem skaitļiem vai hibrīdajām pieejām, NoSQL sistēmas kā MongoDB iet pa citu ceļu.

MongoDB izmanto iebūvētu veidu, ko sauc par ObjectId savam _id laukam. Tas ir 12 baitu binārā vērtība, kas kodē:

• 4 baiti – Laika zīmogs (sekundes no epochs)
• 5 baiti – Nejaušā vērtība (bieži balstīta uz mašīnu + procesa ID)
• 3 baiti – Palielinošs skaitītājs

Piemērs:

507f1f77bcf86cd799439011

Kādēļ MongoDB izvēlas ObjectId

1. Globāli unikāls bez koordinācijas
   Līdzīgi kā UUID, ObjectIds nepieprasa centrālo autoritāti unikalitātes nodrošināšanai, padarot tos ideālus izkliedētam vidēm.
2. Laika sakārtots
   Iebūvētais laika zīmogs nozīmē, ka dokumenti ir hronoloģiskā secībā pēc noklusējuma, kas varētu palīdzēt veiktspējā laika sēriju vaicājumos.
3. Kompakts un efektīvs
   Uzglabāts binārajā formātā, ObjectIds aizņem tikai 12 baitus — daudz mazāk nekā UUID VARCHAR(36). Tie arī ir draudzīgāki indeksēšanai.

ID stratēģiju salīdzinājums

AI izvēles NoSQL kontekstos

Daudzi AI ģenerēti sistēmas izmanto NoSQL konfigurācijas kā MongoDB pēc noklusējuma, kad:

• Tiek gaidīti augsti rakstīšanas vai sadalīšanas
• Shēmām jābūt elastīgām vai daļēji strukturētām
• Datu pārnesamība un izkliedēta mērogošana ir prioritātes

Šādos gadījumos tas bieži ir saprātīgs noklusējuma izvēle izmantot ObjectIds vai līdzīgus unikālus, laika sakārtotus identifikatorus.

PrimeCRM