ШІ та бази даних 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