Сущность по определению должна иметь идентити. Иначе это не сущность. Можно конечно по ссылкам все это разруливать если твои инструменты подобное поддерживают, но тут часто проблема что мы начинаем передавать повсюду саму сущность там где хватило бы ее айдишки увеличивая связанность без явной на то причины. Так же нюансы персистанса что мол айдишка появится только после комита транзакции может сильно повлиять на логику приложения.

По сути у тебя персистанс протекает в систему. В некоторых кейсах это может и не быть проблемой

У автоинкрементов есть два варианта:

- как в MySQL где значение получается при вставке. Тут вариантов нет - персистанс будет просачиваться
- секвенсы где можно получить следующее значение вне транзакции - тут есть варианты мол мы можем перед операцией "создать что-то" запросить идентификатор и передавать его при создании экземпляра явно. Тогда все можно изолировать.

То есть сторадж и что он поддерживает начинает влиять на подходы

Еще можно подумать, может быть штука до назначения id это одна модель, а штука с айдишкой это уже другое. Например, ты регистрируешь нового юзера. Можно сделать отдельно NewUserDetails (нет айдишки в принципе) и UserEntity(id обязательный атрибут)

В целом реляционные базы плохо на ооп ложатся (в целом не только на ооп - на процедурные тоже) так как концепта ссылок у них нет. Потому и городят огромные орм сверху

Кажется не запрещено иметь локальный id и id из базы.

Это если вдруг вам хочется взаимодействовать с объектом про который база ещё не знает - ну например ретраить его вставку в БД если что-то пошло не так.

Это конечно так себе вариант и я сходу не могу придумать кейс в котором это бы перевесило минусы

Хороший вопрос, а что стоило бы использовать? Наверное тот же uuid, какие же ещё варианты, если других уникальных полей нет

я честно слабо представляю ситуацию при которой мы хотим юзать автоинкременты... ну то есть... есть какие-то определенные нюансы с тем что монотонно возрастающая последовательность эффективность и вот это все но все это слабо соотносится с "держать рядом еще один идентификатор". + там где реально от этого профит есть много вставок и возможно надо просто дизайн по другому делать

у uuid есть много вариантов, некоторые варианты сохраняют последовательность. Просто индекс жирнее

Рабочая схема - иметь в базе два ключа - первичный автоинкремент и UUID, но это отчасти для оптимизации было сделано - чтобы явно в API можно было ссылаться UUID-ами. Опять же какие то кейсы можно так поддержать

так а в чем оптимизация? индекс на uuid тебе все так же иметь надо - все накладные расходы uuid мы тащим. Какой профит от автоинкремента тогда? Я понимаю кейс например "мы делаем сервис сокращения ссылок и хотим кодировать автоинкремент просто" но тут уже проблема что такой ключ можно угадать... свои загоны могут быть

а можно штук пять ключей
на каждую версию uuid свой индекс

база данных должна хранить данные и по больше
(сарказм)

Автоинкремент чуть проще для внутренних джойнов, UUID - для ссылок на уровне приложения. Тоже не скажу что по красоте

У нас, например, "новый юзер" и "юзер" это две разные штуки. Ибо есть шардинг, за который отвечает отдельный сервис, в юзер айди закодирован номер шарда.

а что делаете если появляется новый шард ?

А задача в чем? Знать id до вставки в базу?

Кладём новых юзеров в него.

В смысле может он и не нужен ид этот, до вставки.

Ну просто чтобы тривиальные случаи сразу отбросить

Наоборот. До создания сущности и айди не нужен.

Извините, путаю людей в чате