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

Заметной ошибкой является то, что многие схемы баз данных, генерируемые ИИ, в настоящее время склонны использовать 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.

Беседа с ИИ о стратегии 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 базы данных и ObjectIds MongoDB

В то время как реляционные базы данных предлагают гибкость в выборе между 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

Предпочтения ИИ в NoSQL контекстах

Многие системы, генерируемые ИИ, по умолчанию используют NoSQL конфигурации, подобные MongoDB, когда:

• Ожидается высокая пропускная способность записи или шардинг
• Схемы должны быть гибкими или полуструктурированными
• Переносимость данных и распределенное масштабирование являются приоритетами

В таких случаях использование ObjectIds или подобных уникальных, упорядочиваемых по времени идентификаторов часто является разумным выбором по умолчанию.

PrimeCRM