Comments 7
«Сначала роль, потом формат» — попадание. В WordPress это буквально три разных мира: ID, slug, nonce. Смешать slug с идентичностью в meta/REST — классика боли через полгода. Таблица в конце — must have для ревью.
Хорошая статья. Добавлю из практики: UUIDv4 на B-tree индексах в Postgres даёт сильную фрагментацию — вставка рандомных значений заставляет дерево постоянно перестраиваться. Если нужен UUID для первичного ключа, смотрите в сторону UUIDv7 (time-sorted) или ULID — они ложатся почти последовательно и индекс живёт намного дольше без вакуума.
Забыто еще одно важное (кардинальное) отличие int от uuid для id: uuid мы можем безопастно сгенерить для сущности, работать с ней, создавать связанные и потом все это одной транзакцией спокойно засунуть в базу. А при использовании int - мы практически обязаны использовать автоинкремент базы и сохранять сущности чтобы получить их назначенные id для использования
Да, согласен, это хороший плюс UUID/ULID/ObjectId: id можно сгенерировать на стороне приложения до записи в базу, собрать связанные сущности и сохранить весь граф одной транзакцией.
Но “с int практически обязаны сначала сохранить” — это не так. В SQL-базах есть sequence/nextval, INSERT ... RETURNING, ORM flush без commit, заранее выделенные диапазоны id. То есть проблема решаемая, причем несколькими способами.
Я бы сформулировал отличие чуть иначе: при автоинкременте база обычно владеет генерацией id, а приложение синхронизируется с ней. При UUID/ULID/ObjectId генерацией может и чаще всего владеет приложение, и это действительно удобнее для, например, сборки связанных объектов до сохранения.
хранить его как обычное поле token рядом с user_id — плохая привычка. Это удар по безопасности. api_key лучше не показывать повторно и не хранить открытым текстом
Есть ссылки на авторитетные источники?
Какая-то это сомнительная идея:
1) Пространство значений токена много больше пространства значений хэш-функции. Условно, токен был 2048-битный, а в бд вы сохраните какой-нибудь sha-256. И в чем профит?
2) В запросах к бекенду клиенты передают токен в открытом виде.
Смысл хэширования токена не в том, что SHA-256 улучшает 2048-битный токен.
Смысл в другом: значение в базе не должно быть готовым credential.
Да, клиент предъявляет токен в открытом виде, но это не значит, что бэк должен хранить его в сыром виде. При проверке можно принять токен, посчитать hash/HMAC и сравнить с тем, что лежит в базе.
Если утечёт сырой токен — его можно сразу использовать. Если утечёт hash — его нельзя предъявить как токен.
ID, token, UUID и slug: в чём разница и почему их нельзя мешать