ІІ і базы дадзеных MySQL

Гэта сур'ёзная памылка, што многія схемы баз даных, згенераваныя ШІ, у цяперашні час схільныя выкарыстоўваць VARCHAR(36) для калонкі id.

Гэта звычайна матывавана жаданнем прадухіліць несанкцыянаваны доступ з боку злосных акцёраў. Для дасягнення гэтага UUID (Універсальныя ўнікальныя ідэнтыфікатары) часта выкарыстоўваюцца як мера бяспекі.

Возьмем WordPress як прыклад — ён звычайна раскрывае ідэнтыфікатары паведамленняў у URL як ?p=45. У параўнанні з SEO-зручным фарматам, такім як /2025/05/sample-post, гэты лічбавы ідэнтыфікатар дазваляе карыстальнікам патэнцыйна ацэньваць і атрымліваць доступ да прылеглага зместу, змяняючы нумар (напр. ?p=44). UUID, з іншага боку, не з'яўляюцца паслядоўнымі і значна складанейшыя для здогадкі.

UUID - гэта 36-сімвальныя радкі, якія следуюць стандартнаму фармату з пяццю секцыямі, падзеленымі злучкамі: 8-4-4-4-12. Кожная секцыя складаецца з шаснаццатковых значэнняў:

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

Просты regex для праверкі UUID выглядае так:

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

Хоць UUID забяспечваюць бяспеку і партатыўнасць, яны прыходзяць з кампрамісамі. Яны значна большыя за цэлыя лікі, што можа запаволіць прадукцыйнасць базы даных — асабліва пры выкарыстанні ў якасці першасных ключоў у рэляцыйных базах даных. Індэксацыя, выкарыстанне памяці і хуткасць запытаў усё пакутуюць з-за памеру і неслядовага характару UUID.

Размова ШІ пра стратэгію ідэнтыфікатараў

Цікавячыся гэтым выбарам дызайну, я паставіў гэтае пытанне GitHub Copilot:

Я:
Чаму вы выбралі вызначыць калонку id як VARCHAR(36) PRIMARY KEY у структуры базы даных?

GitHub Copilot:

Я выбраў VARCHAR(36) для калонак ID па некалькіх канкрэтных прычынах:

1. Захоўванне UUID: Даўжыня ў 36 сімвалаў адпавядае значэнням UUID, якія следуюць стандартызаванаму фармату.
2. Мультыарэнднія сістэмы: UUID дапамагаюць ізаляваць арэндатараў, ліквідуючы ўцечкі паслядоўных ідэнтыфікатараў, спрашчаючы міграцыі і палепшаючы бяспеку.
3. Партатыўнасць даных: UUID забяспечваюць, што экспартаваныя даныя не маюць канфліктаў ідэнтыфікатараў пры імпарце ў іншую сістэму.

Кампрамісы:

• Большы памер захоўвання (36 байтаў супраць 4 байтаў для INT)
• Павольнейшая прадукцыйнасць індэксацыі і запытаў
• Большае выкарыстанне памяці

Альтэрнатывы для разгляду:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) для больш эфектыўнага захоўвання сырых байтаў UUID
3. Уласная стратэгія генерацыі ідэнтыфікатараў

Дайце мне ведаць, калі вы аддаеце перавагу іншаму падыходу.

Я:
Выкарыстоўвайце BIGINT UNSIGNED для прадукцыйнасці, але захоўвайце поле guid у кожным запісе для знешніх спасылак.

GitHub Copilot:

Я абнаўлю схему для выкарыстання BIGINT UNSIGNED для першасных ключоў і дадам калонку guid для знешніх спасылак. Гэты гібрыдны падыход спалучае лепшае з абедзвюх стратэгій:

• Прадукцыйнасць: Эфектыўная індэксацыя і аб'яднанне праз лічбавыя першасныя ключы
• Бяспека і партатыўнасць: GUID выкрытыя ў API, утрымліваючы ўнутраныя ідэнтыфікатары бяспечнымі ад пералічэння

Рэзюме:

• BIGINT UNSIGNED: Хуткі, кампактны, паслядоўны
• GUID (VARCHAR): Унікальны, партатыўны, знешне бяспечны

Базы даных NoSQL і MongoDB ObjectIds

У той час як рэляцыйныя базы даных прапаноўваюць гнуткасць у выбары паміж UUID, цэлымі лікамі або гібрыднымі падыходамі, сістэмы NoSQL, такія як MongoDB, ідуць іншым шляхам.

MongoDB выкарыстоўвае ўбудаваны тып пад назвай ObjectId для свайго поля _id. Гэта 12-байтовае двайковае значэнне, якое кадуе:

• 4 байты – Часавая адбітка (секунды ад эпохі)
• 5 байтаў – Выпадковае значэнне (часта заснаванае на машыне + ідэнтыфікатар працэсу)
• 3 байты – Інкрэментальны лічыльнік

Прыклад:

507f1f77bcf86cd799439011

Чаму MongoDB выбірае ObjectId

1. Глабальна ўнікальны без каардынацыі
   Як і UUID, ObjectIds не патрабуюць цэнтральнай улады для забеспячэння ўнікальнасці, што робіць іх ідэальнымі для размеркаваных асяроддзяў.
2. Упарадкавныя па часу
   Убудаваная часавая адбітка азначае, што дакументы знаходзяцца ў храналагічным парадку па змаўчанні, што можа дапамагчы прадукцыйнасці ў запытах часовых радоў.
3. Кампактны і эфектыўны
   Захаваныя ў двайковым фармаце, ObjectIds займаюць толькі 12 байтаў — значна менш за UUID VARCHAR(36). Яны таксама больш зручныя для індэксацыі.

Параўнанне стратэгій ідэнтыфікатараў

Выбары ШІ у кантэкстах NoSQL

Многія згенераваныя ШІ сістэмы выкарыстоўваюць канфігурацыі NoSQL, такія як MongoDB, па змаўчанні, калі:

• Чакаюцца высокія запісы або шардзінг
• Схемы павінны быць гнуткімі або паўструктураванымі
• Партатыўнасць даных і размеркаванае маштабаванне з'яўляюцца прыярытэтамі

У такіх выпадках часта з'яўляецца разумным выбарам па змаўчанні выкарыстанне ObjectIds або падобных унікальных, упарадкаваных па часу ідэнтыфікатараў.

PrimeCRM