AI og MySQL gagnagrunnar

Það er mikilvæg villa sem mörg AI-mynduð gagnagrunnskerfi nota nú á dögum að nota VARCHAR(36) fyrir id dálkinn.

Þetta er venjulega hvatt af löngun til að hindra óheimilaðan aðgang frá illgjörðamönnum. Til að ná þessu er UUID (Universal Unique Identifiers) oft notað sem öryggisráðstöfun.

Tökum WordPress sem dæmi — það afhjúpar venjulega færsluauðkenni í URL-inu sem ?p=45. Í samanburði við SEO-vænna snið eins og /2025/05/sample-post, gerir þetta töluauðkenni notendum kleift að meta og aðgang að nærliggjandi efni með því að breyta númerinu (t.d. ?p=44). UUID eru hins vegar ekki í röð og eru mun erfiðari að giska á.

UUID eru 36 stafa strengir sem fylgja stöðluðu sniði með fimm hlutum aðskildum með striki: 8-4-4-4-12. Hver hluti samanstendur af sextán tölugildlum:

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

Einföld regex til að sannreyna UUID lítur svona út:

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

Þó að UUID veiti öryggi og flutningsgetu, þá koma þau með málamiðlun. Þau eru umtalsvert stærri en heiltölur, sem gæti hægt á frammistöðu gagnagrunns — sérstaklega þegar þau eru notuð sem aðallyklar í tengslaga gagnagrunnum. Skráning, minnisnotkun og fyrirspurnahraði þjáist öll vegna stærðar og óröðuðs eðlis UUID.

AI-samtal um auðkennisstefnu

Forvitinn um þetta hönnunarval spurði ég eftirfarandi spurningu til GitHub Copilot:

Ég:
Hvers vegna valdir þú að skilgreina id dálkinn sem VARCHAR(36) PRIMARY KEY í gagnagrunnsuppbyggingunni?

GitHub Copilot:

Ég valdi VARCHAR(36) fyrir ID dálka af nokkrum ástæðum:

1. UUID-geymsla: 36 stafa lengdin rúmar UUID gildi, sem fylgja stöðluðu sniði.
2. Fjölleigjandakerfi: UUID hjálpar til við að einangra leigjendur með því að eyða röðunarauðkenni leka, einfaldaða flutning og bætta öryggi.
3. Gagnaflutningsgeta: UUID tryggir að útflutt gögn hafi engar ID árekstra þegar þau eru flutt inn í annað kerfi.

Málamiðlanir:

• Stærri geymslustærð (36 bæti á móti 4 bætum fyrir INT)
• Hægari skráningar- og fyrirspurnarframmistaða
• Meiri minnisnotkun

Valkostir til íhugunar:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) til að geyma hrá UUID bæti á skilvirkari hátt
3. Sérsniðin auðkennismyndunaráætlun

Láttu mig vita ef þú vilt frekar aðra nálgun.

Ég:
Notaðu BIGINT UNSIGNED fyrir frammistöðu, en haltu guid reit í hverri skrá fyrir ytri tilvísanir.

GitHub Copilot:

Ég mun uppfæra skemað til að nota BIGINT UNSIGNED fyrir aðallykla og bæta við guid dálki fyrir ytri tilvísanir. Þessi blendingsaðferð sameinar það besta úr báðum áætlunum:

• Frammistaða: Skilvirk skráning og samsetning í gegnum tölulega aðallykla
• Öryggi og flutningsgeta: GUID afhjúpað í API-um, halda innri auðkennum öruggum frá upptalningum

Samantekt:

• BIGINT UNSIGNED: Hratt, þjappað, röðuð
• GUID (VARCHAR): Einstakt, flutjanlegt, öruggt ytra

NoSQL gagnagrunnar og MongoDB ObjectIds

Þó að tengslagar gagnagrunnar bjóði upp á sveigjanleika í vali milli UUID, heiltalna eða blendingsaðferða, þá taka NoSQL kerfi eins og MongoDB aðra leið.

MongoDB notar innbyggða tegund sem kallast ObjectId fyrir _id reitinn. Þetta er 12-bæta tvíundargildi sem kóðar:

• 4 bæti – Tímastimpill (sekúndur frá tímabilinu)
• 5 bæti – Handahófskennt gildi (oft byggt á vél + ferlis-ID)
• 3 bæti – Stigvaxandi teljari

Dæmi:

507f1f77bcf86cd799439011

Hvers vegna velur MongoDB ObjectId

1. Alþjóðlega einstakt án samhæfingar
   Líkt og UUID þurfa ObjectIds ekki miðlægt vald til að tryggja einstakleika, sem gerir þau tilvalin fyrir dreifð umhverfi.
2. Tímaraðað
   Innbyggði tímastimpillinn þýðir að skjöl eru í tímaröð að sjálfgefnu, sem gæti hjálpað frammistöðu í tímaraðafyrirspurnum.
3. Þjappað og skilvirkt
   Geymt í tvíundarsniði, ObjectIds taka aðeins 12 bæti — mun minna en UUID VARCHAR(36). Þau eru líka vænni fyrir skráningu.

Samanburður auðkennisáætlana

AI-val í NoSQL samhengi

Mörg AI-mynduð kerfi nota NoSQL uppsetningu eins og MongoDB að sjálfgefnu þegar:

• Búist er við miklum skrifum eða skiptingu
• Skemu þarf að vera sveigjanleg eða hálfuppbyggð
• Gagnaflutningsgeta og dreifð skölunarfærni eru forgangsatriði

Í slíkum tilfellum er það oft skynsamlegt sjálfgefið val að nota ObjectIds eða svipuð einstök, tímaröðuð auðkenni.

PrimeCRM