ИИ и MySQL бази данни

Забележима грешка е, че много AI генерирани схеми на бази данни в момента са склонни да използват VARCHAR(36) за колоната id.

Това обикновено е мотивирано от желание да се предотврати неоторизиран достъп от злонамерени участници. За да постигнат това, UUID (Universally Unique Identifiers) често се използват като мярка за сигурност.

Да вземем WordPress като пример — типично експонира ID-та на постовете в URL като ?p=45. В сравнение с SEO-дружелюбен формат като /2025/05/sample-post, този числов ID позволява на потребителите потенциално да отгатват и да получават достъп до съседно съдържание чрез промяна на числото (напр. ?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

Просто регулярно израз за валидиране на 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.

AI разговор за стратегия за ID

Заинтересован от този избор на дизайн, попитах GitHub Copilot следния въпрос:

Аз:
Защо избрахте да дефинирате колоната id като VARCHAR(36) PRIMARY KEY в структурата на базата данни?

GitHub Copilot:

Избрах VARCHAR(36) за колоните ID по няколко специфични причини:

1. UUID съхранение: 36-символната дължина побира UUID стойности, които следват стандартизиран формат.
2. Мултитенантни системи: UUID помагат за изолиране на наемателите чрез елиминиране на последователни ID утечки, опростяване на миграциите и подобряване на сигурността.
3. Преносимост на данни: UUID гарантират, че експортираните данни няма да претърпят ID колизии при импортиране в друга система.

Компромиси:

• По-голям размер на съхранение (36 байта срещу 4 байта за INT)
• По-бавна производителност на индексиране и заявки
• По-голямо използване на памет

Алтернативи за разглеждане:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) за по-ефективно съхранение на сурови UUID байтове
3. Персонализирана стратегия за генериране на ID

Уведомете ме ако предпочитате различен подход.

Аз:
Използвайте BIGINT UNSIGNED за производителност, но запазете поле guid във всеки запис за външни препратки.

GitHub Copilot:

Ще обновя схемата да използва BIGINT UNSIGNED като първичен ключ, като добавя колона guid за външни препратки. Този хибриден подход комбинира най-доброто от двете стратегии:

• Производителност: Ефективно индексиране и свързвания чрез числови първични ключове
• Сигурност и преносимост: GUID експонирани в API, запазвайки вътрешните ID безопасни от изброяване

Резюме:

• BIGINT UNSIGNED: Бърз, компактен, последователен
• GUID (VARCHAR): Уникален, преносим, външно безопасен

NoSQL бази данни и MongoDB ObjectIds

Докато релационните бази данни предлагат гъвкавост в избора между UUID, цели числа или хибриди, NoSQL системите като MongoDB вземат различен път.

MongoDB използва вграден тип наречен ObjectId за своето поле _id. Това е 12-байтова двоична стойност, която кодира:

• 4 байта – Времева марка (секунди от епохата)
• 5 байта – Случайна стойност (често базирана на машина + ID на процес)
• 3 байта – Инкрементален брояч

Пример:

507f1f77bcf86cd799439011

Защо MongoDB избира ObjectId

1. Глобално уникален без координация
   Подобно на UUID, ObjectIds не изискват централен орган за гарантиране на уникалност, правейки ги идеални за разпределени среди.
2. Подреден по време
   Вградената времева марка означава, че документите са подредени хронологично по подразбиране, което може да помогне с производителността в приложения за времеви серии.
3. Компактен и ефективен
   Съхранявани в двоичен формат, ObjectIds заемат само 12 байта — много по-малко от UUID VARCHAR(36). Те също са по-дружелюбни към индексирането.

Сравнение на стратегии за ID

AI предпочитания в NoSQL контексти

Много AI генерирани системи по подразбиране използват NoSQL конфигурации подобни на MongoDB когато:

• Се очаква висока пропускателна способност за запис или шардиране
• Схемите трябва да бъдат гъвкави или полуструктурирани
• Преносимостта на данните и разпределеното мащабиране са приоритети

В такива случаи използването на ObjectIds или подобни уникални, подреждаеми по време идентификатори често е разумен избор по подразбиране.

PrimeCRM