Здравствуйте, такой вопрос: есть таблица users, у каждого пользователя есть

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

Есть вариант разбить всё на таблицы (user_likes_limits, user_groups_limits, и т.д. аналогично для каждого ограничения) с полями user_id, value, updated_at соответственно в каждой таблице.

Но не выглядит ли это слишком громоздко? По сути данные уже перестают быть данными и вылазят в схему: для каждого нового ограничения — новая однотипная таблица.
Есть вариант вынести сами ограничения в отдельную таблицу limits и создать таблицу связности user_limits с полями user_id, limit_id, value, updated_at.

Какой вариант является более правильным? (возможно ни один)
P.S. Связь, получается, один к одному (Postgres)

Не вижу смысла разбивать на таблицы, что меняется?

В разных таблицах value может быть разного типа

Если, например, ограничение — булевый флаг

У разных полей одной таблицы типы могут быть также разные как и у разных полей разных таблиц

Поэтому я нифига не понял

Ты имеешь ввиду вообще не разделять? Оставить эти поля в таблице users ибо 1:1?

Да, не виду смысла вообще

Тут ключевой момент -надо ли будет расширять состав этих ограничений во время работы системы, надо ли добавлять новые виды ограничений? Если да, то -дочерняя таблица, если нет - можно делать поля

sql_variant (SQL Server) anydata (Oracle) если только числовые или битовые, то можно не заморачиваться - 0 и 1 решают

Я бы оставил таблицу users и отдельно таблицу с ограничениями. Судя из описания вид второй таблицы получится такой: id user_id ограничение updated_at Получается ты добавляешь на одного юзера несколько строк, где поле ограничение это like, limit и т.д. Удобно и легко можно расширять

Ограничение тогда — enum какой-то? Если там строго один из вариантов

когда понадобится переименовать like или limit (несколько раз), а потом построить отчет по ограничениям определенного типа либо добавить к сущности "ограничение" атрибут-другой и построить отчет по этим атрибутам, тут то все удобство и проявится.

Да, enum, как вариант. Зависит от проекта конечно) можно просто подвязываться к этому полю и выводить в цикле в шаблоне. Если появится новое ограничение - шаблон просто среагирует и сразу выведет. По мне так очень удобно

Согласен. Тоже рассматривал, но динамический тип в постгресе — что-то не уверен

enum в реляционках насколько знаю — не желателен. А что за шаблоны?

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

Да это я образно) я веб разработчик просто, с бэкенда допустим идёт таблица, нужно в цикле выводить данные сгруппированные по определённому полю. Я вытягиваю уникальные значения этого поля, заношу в массив, потом в цикле иду по массиву и отрисывываю нужный шаблон в интерфейсе) Вообщем проектирование БД зависит ещё и от проекта, что-то одно универсальное сложно сделать) иногда я использую enum, иногда подвязываюсь к таблице в БД, чтобы при новом значении моя система сразу его подцепила)

А пустые поля тогда не проблема?

А зачем id ?

Согласен, поспешил, привычка подставлять уникальное поле)