Здравствуйте, wildwind, Вы писали:

vsb>>4. Читабельность. Ну тут целые числа однозначно приятней глазу, чем UUID.

W>Если нужен читабельный пользователями ID, лучше завести отдельный ключ, отличный от PK. Даже если PK это такой же int.

Речь про читабельность для программиста/админа. Например я могу сделать select, увидеть там id=12762 и без копипаста напечатать его же в следующем запросе. С UUID это невозможно.

W>И 2.2 и 2.3 можно перебирать/подбирать. Чуть сложнее, чем 1, но вполне успешно.

Сомневаюсь. Даже 32 бита ты не переберёшь, тебя задолго до этого забанит чего-нибудь. В общем это не то, что обычно понимают под перебором.

vsb>>Также есть проблема с реализацией вариантов 2.2 и 2.3, это не слишком часто используемые подходы и возможно придется использовать редкие библиотеки или писать самому. Это не великая проблема, но всё же.

W>Не вижу проблемы. Библиотек полно, и все современные ОС предоставляют подобный сервис.

Ну приведи пример для postgres. Что за современные ОС, у меня alpine linux, что за сервис ты имеешь в виду?

W>Главное помнить, что best practices это не догмы, а рекомендации. Подходы вполне можно совмещать, даже в рамках одной БД.
W>Таблицы-справочники, меняющиеся раз в год, и таблицы-перечисления, на которые ссылается полбазы, вполне могут жить с целочисленными ключами. Особенно если ключи укладываются, скажем, в байт. Проблемы генерации ключа на клиенте (раз в год) их не касаются.

В моём понимании смысл best practices в том, чтобы не отходить от них без существенных причин. Поэтому таблицы справочники точно будут с UUID в такой модели, по крайней мере я не вижу ни одной причины исключать их. А использовать там однобайтовые идентификаторы это каноничный premature optimization, который с очень ощутимой вероятностью выстрелит лет через 5, когда придётся делать миграцию половины таблиц на более широкий тип. Но в целом, конечно, согласен, если очень надо — без проблем, это не догма.