данных (типа пароля, токена, роли и прочей прикладной инфы)? А то вот отделяю, несколько плюсов в этом подходе вижу, но таких, чтобы сказать мол очевидно так надо делать - не нахожу
все дело в самой таблице , некоторые orm не умеют выбирать не всю строку а только часть строки из таблицы, и поэтому если там будет много полей - это создаст нагрузку - однако если вы выбираете обычными select только то что вам нужно то количество полей не будет влиять на производительность
что за токен ты там хранишь?
жесткий
Да вот мы монгу используем, но да пофиг, то есть кроме как выборки определенных полей проблем нет?
В твоём случае - очевидно надо разделять Токен меняется часто, а имя или фамилия пользователя - редко Токенов может быть несколько (вариативно) Не каждый пользователь может иметь право логиниться (вариативно) И, наконец, это (данные для входа и профиль пользователя) просто разные сущности
Ну вот я из той же логики исхожу, что тут сущности семантически разные, меняются по разному + ещё и назначения разные. Вот просто так получается, что так и хочется оставлять, а коллеги считают, что надо в одну таблицу сгрести эти данные, типа проще работать будет. А я аргументов, кроме семантики да ддд не нахожу)
Identity and access management окей выделять отдельным доменом и отдельно моделировать. У него своя ответственность. А вот хранить это в одной таблице или нет, уже чуть другая проблема. Хранение данных вместе это плюс для чтения, меньше i/o к диску будет
Если читал красную книжку вернона, то он, если не ошибаюсь, в самом начале проводит как раз пример отделения iam домена
Обсуждают сегодня