А в качестве первичного ключа что лучше использовать: uuid или

Int?

Я б не трогал uuid для учебных задач, если задача не в этом.

Почему?

It depends. По-умолчанию лучше использовать int \ bigint если у тебя нет специфических требований.

Он приносит свои приколы при реализации, которые надо понимать.

Какие?

?

Место жрёт, сортировки нет (при поиске каких-нибудь дублей может быть актуально), шардинг по модулю id идёт лесом. Ну и ещё пачка подобных нюансов.

Я бы даже сказал если у тебя постгрес, то следует использовать id BIGINT GENERATED ALWAYS AS IDENTITY

Это как это сортировки нет?

там в генерации ж таймстамп учавствует, сортировка работает

Ну это нюансы, да. Но можно хранить и то и то. Для пет проекта в целом пофиг на эти вещи как я выше сказал

То пет, а то учебный. Банально пока дебажить будет, задолбается копипастить, чтобы разобраться, что к чему привязано.

Преувеличиваешь) у нас все на юидах, это не является какой-то проблемой

Не знаю, пока мы не строим что-то распределённое и не знаем, зачем ещё нам нужен uuid, я всё ещё считаю, что это оверкилл без каких-либо плюсов. Банально можно себе всрать производительность на ровном месте.

Я придерживаюсь мнению что возвращать наружу стоит почти всегда только ююид. Если ничего не возвращаешь наружу то пожалуйста, используй инты

Зачем снаружи уид и что наружа будет с ним делать?

Представь что Ты делаешь апишку для клиентов. Стало понятнее?

It depends. Во-первых, кто сказал, что api должно где-то первичный ключ возвращать?

Я говорил про то что наружу надо отдавать юиды, а не про то что они должны быть первичным ключем

Я не вижу проблемы возвращать наружу инты, если у тебя контроль доступа не обеспечивается одними лишь идентификаторами

А я слишком много видел и знаю что в любой достаточно большой системе неизбежны баги, и возможно в том числе с access control) Теория хаоса, все дела 😁

спасибо

Это уже близко к security through obscurity.

В каком-то смысле да. Но вообще это всегда баланс. Обычно цена хранения юида не превышает дополнительных гарантий безопасности

Но я в каком-то смысле предвзят, потому что занимался поиском таких уязвимостей) Это как полицейские видят везде преступников)

Вот с этим тезисом, пожалуй, соглашусь.

Каких именно гарантий? Важно понять, от чего мы защищаемся и не делаем ли мы хуже. Например, часто уходят от последовательных ID чтобы скрыть порядок и время создания сущностей. И тут приходим мы с uuid. Но чтоб не разломать сортировку, мы делаем его ulid. В итоге — таймстемп читается прямо из уида. Круто?

Я про ulid ничего не говорил это раз. Порядок создания сущностей, бизнес метрики, это все можно случайно спалить. Дальше - при проблемах с acces-control имеем IDOR. Весьма Неприятно в некоторых случаях

А я о том, что "отдавать уид" само по себе ничего не лечит, а может сделать хуже чем было (полный таймстемп вместо просто порядка). Важно понимать, что и от чего мы защищаем и исходя из этого выбирать меры.

Спорное "круто", потому что время создание и обработки сущности становится выше, не говоря про другие возможные проблемы. Uuid, как и его разновидность ulid, не являются серебряной пулей...

Собвтвенно, про то и речь.

👍🏻

Вообще важно понимать что делаешь, тут не поспоришь 😁 Но если ты аргументом выбрал что «можно накосячить», то это ровно тот же самый аргумент который можно применить и в мою пользу)

Ну, решение с UUID заведомо сложнее и создаёт видимость защиты от чего-то. Так что нет, нельзя применить.

Я не вижу какой-то значительной сложности в использовании ююида. Idor’ы почти всегда плохо.