AI a Chronfeydd Data MySQL

Mae'n wall arwyddocaol bod llawer o sgêmau cronfa ddata a gynhyrchir gan AI ar hyn o bryd yn tueddu i ddefnyddio VARCHAR(36) ar gyfer y golofn id.

Mae hyn fel arfer yn cael ei gymell gan awydd i atal mynediad heb awdurdod gan actorion maleisus. I gyflawni hyn, defnyddir UUID (Adnabyddwyr Unigryw Cyffredinol) yn aml fel mesur diogelwch.

Gadewch i ni gymryd WordPress fel enghraifft — mae'n datgelu ID postiadau yn yr URL fel arfer fel ?p=45. O'i gymharu â fformat SEO-gyfeillgar fel /2025/05/sample-post, mae'r ID rhifol hwn yn caniatáu i ddefnyddwyr o bosibl asesu a chael mynediad at gynnwys cyfagos trwy newid y rhif (e.e. ?p=44). Mae UUID ar y llaw arall yn anghymryd ac yn llawer anoddach i'w dyfalu.

Mae UUID yn striciau 36 nod sy'n dilyn fformat safonol gyda phum adran wedi'u gwahanu gan gysylltnodau: 8-4-4-4-12. Mae pob adran yn cynnwys gwerthoedd hecsadegol:

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

Mae regex syml i ddilysu UUID yn edrych fel hyn:

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

Er bod UUID yn darparu diogelwch a chludioedd, maent yn dod gyda chyfaddawdau. Maent yn sylweddol fwy na chyfanrifau, a all arafu perfformiad cronfa ddata — yn enwedig pan gânt eu defnyddio fel allweddi cynradd mewn cronfeydd data perthynol. Mae mynegeio, defnydd cof a chyflymder ymholiadau i gyd yn dioddef oherwydd maint a natur anghymryd UUID.

Sgwrs AI am strategaeth ID

Yn chwilfrydig am y dewis dylunio hwn, gofynnais y cwestiwn hwn i GitHub Copilot:

Fi:
Pam y gwnaethoch chi ddewis diffinio'r golofn id fel VARCHAR(36) PRIMARY KEY yn strwythur y gronfa ddata?

GitHub Copilot:

Dewiswyd VARCHAR(36) ar gyfer colofnau ID am sawl rheswm penodol:

1. Storio UUID: Mae hyd 36 nod yn gweddu i werthoedd UUID, sy'n dilyn fformat safonedig.
2. Systemau aml-denant: Mae UUID yn helpu i ynysu tenantiaid trwy ddileu gollyngiadau ID cymryd, symleiddio mudo a gwella diogelwch.
3. Cludioedd data: Mae UUID yn sicrhau nad oes gan ddata a allforir wrthdaro ID wrth eu mewnforio i system arall.

Cyfaddawdau:

• Maint storio mwy (36 beit vs 4 beit ar gyfer INT)
• Perfformiad mynegeio ac ymholi arafach
• Defnydd cof uwch

Dewisiadau i'w hystyried:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) i storio beitiau UUID crai yn fwy effeithlon
3. Strategaeth cynhyrchu ID wedi'i phersonoli

Rhowch wybod i mi os byddech yn well gennych ddull gwahanol.

Fi:
Defnyddiwch BIGINT UNSIGNED ar gyfer perfformiad, ond cadwch faes guid ym mhob cofnod ar gyfer cyfeiriadau allanol.

GitHub Copilot:

Byddaf yn diweddaru'r sgema i ddefnyddio BIGINT UNSIGNED ar gyfer allweddi cynradd ac yn ychwanegu colofn guid ar gyfer cyfeiriadau allanol. Mae'r dull hybrid hwn yn cyfuno'r gorau o'r ddwy strategaeth:

• Perfformiad: Mynegeio effeithlon ac ymuno trwy allweddi cynradd rhifol
• Diogelwch a chludioedd: GUID wedi'u datgelu mewn API, gan gadw ID mewnol yn ddiogel rhag rhifo

Crynodeb:

• BIGINT UNSIGNED: Cyflym, cryno, cymryd
• GUID (VARCHAR): Unigryw, cludadwy, allanol ddiogel

Cronfeydd data NoSQL a MongoDB ObjectIds

Tra bod cronfeydd data perthynol yn cynnig hyblygrwydd i ddewis rhwng UUID, cyfanrifau neu ddulliau hybrid, mae systemau NoSQL fel MongoDB yn cymryd llwybr gwahanol.

Mae MongoDB yn defnyddio math adeiledig o'r enw ObjectId ar gyfer ei faes _id. Mae hwn yn werth deuaidd 12-beit sy'n amgodio:

• 4 beit – Stamp amser (eiliadau o'r epoc)
• 5 beit – Gwerth ar hap (yn aml yn seiliedig ar beiriant + ID proses)
• 3 beit – Rhifydd cynyddol

Enghraifft:

507f1f77bcf86cd799439011

Pam mae MongoDB yn dewis ObjectId

1. Unigryw yn fyd-eang heb gydlynu
   Fel UUID, nid oes angen awdurdod canolog ar ObjectIds i sicrhau unigrywedd, gan eu gwneud yn ddelfrydol ar gyfer amgylcheddau dosbarthedig.
2. Wedi'u trefnu yn ôl amser
   Mae'r stamp amser cynwysiedig yn golygu bod dogfennau mewn trefn gronolegol yn ddiofyn, a all helpu perfformiad mewn ymholiadau cyfres amser.
3. Cryno ac effeithlon
   Wedi'u storio mewn fformat deuaidd, mae ObjectIds yn cymryd dim ond 12 beit — llawer llai na UUID VARCHAR(36). Maent hefyd yn fwy cyfeillgar i fynegeio.

Cymhariaeth strategaethau ID

Dewisiadau AI mewn cyd-destunau NoSQL

Mae llawer o systemau a gynhyrchir gan AI yn defnyddio ffurfweddiadau NoSQL fel MongoDB yn ddiofyn pan:

• Disgwylir ysgrifeniadau uchel neu sharding
• Rhaid i sgêmau fod yn hyblyg neu'n lled-strwythuredig
• Mae cludioedd data a graddio dosbarthedig yn flaenoriaethau

Mewn achosion o'r fath, mae'n aml yn ddewis diofyn doeth defnyddio ObjectIds neu adnabyddwyr unigryw tebyg, wedi'u trefnu yn ôl amser.

PrimeCRM