День добрый. Подскажите пожалуйста. Есть такая таблица: CREATE TABLE "user_notification_settings" (

"id" bigserial,
"type" varchar(50) NOT NULL,
"method" varchar(50) NOT NULL,
"user_id" int8 NOT NULL,
"created_at" timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
"created_by" varchar(50) NOT NULL DEFAULT 'System',
"last_modified_at" timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
"last_modified_by" varchar(50) NOT NULL DEFAULT 'System',
CONSTRAINT "user_notification_settings_pk" PRIMARY KEY ("id")
);

Где type - новости, изменения аккаунта и прочее прочее, а method - Email, WebSite, Telegram (то бишь место где можно получать уведомления).
В эти колонки пишутся имена констант из enum-а.

Нормально ли это все хранить в одной таблице или лучше сделать две таблицы справочники user_notification_settings_method и user_notification_settings_type и в таблице выше делать связывать записи?

Оба норм. Ещё можно для постгре заморочиться: объявить на стороне базы енам тип, сделать кастомный тип в хибере

если не предполагается добавление значений (а они, я так понимаю, зависят от реализации) то можно и в одной таблице. лукап таблицы обычно пишут если значения могут измениться

Добавляться новые значения будут в ENUM в java коде. Это добавление повлияет на UI ну и в бд при сохранении новых данных. По сути это все. Но это не данные, которые изменяются часто.

Это нужно как-то будет следить за тем, что в enum-е и постгре одинаковые значения.

я имел в виду добавление значений без изменения реализации)

реализаций чего?

сервиса, который использует данную таблицу

но енам не удобен еще когда между ветками переключаешься - сыпет ошибки при попытке записи значений, которых нет в базе, а это часто бывает когда хочешь на старую ветку перейти, где этот элемент енама по другому назывался, так что стринг the best, хоть и весит больше

Нафига? Ну вот нафига энам в бд? Что бы в двух местах поддерживать? Что бы было нормально делаем инт поле в базе, что бы не использовать ordinal - делаем в энаме явное поле с числом и кастомный сериализатор. Потом на это делается индекс и все, при необходимости, и то от этого индекса не сильно горячо или холодно, вариантов сильно меньше записей в таблице обычно

я не предлагал создать енам в бд, я предлагал вынести денормализованные поля в справочники и проставить нормальные связи енам или класс с пачкой статичных полей на беке использовать исключительно как место хранения констант для случаев когда в бизнес-логике требуется какое-то заранее известное значение из справочника чтобы его засетить куда-нибудь наверное мне стоило изъясняться яснее

Единственное что меня напрягает со справочниками - нужно контролировать наполнение справочников ибо может быть всякое.

Так а нахрена копия енама в виде справочника в таблице в бд?) Цель какая? Что это даст?

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

Каких магических констант? У тебя энам в коде, там все четко определенно. Ты не ответил зачем его копия в базе?