Нужна ли здесь связь 1:1 вместо расширения таблицы?
Есть табличка user с вполне стандартными полями и полем updated_at (ну так надо).
Помимо этого я веду статистику для пользователей в таком виде, что ее можно просто добавить в таблицу user в новых полях или выделить в отдельную таблицу user_stats со связью 1:1 с user.
Во втором случае я выделяю отдельную сущность и могу например добавить в user_stats поле updated_at, явно указывая, что это время обновления именно статистики. Иначе (в случае одной таблицы user) мне пришлось бы уточнять имя этого поля как stats_updated_at, при этом не понятно за обновление каких полей отвечает этот stats_updated_at и просто updated_at.
В общем выделение отдельной таблицы user_stats видится более кошерным, но при этом придется мириться с джойном user+user_stats при запросах.
Как поступаете вы?
Update 1:
А можно как-то выкрутиться при помощи views/наследования/других фич postgres'а явно выделив две сущности, при этом избежав 1:1 и следовательно джойна?
Пусть есть широкая некошерная таблица T с данными по юзерам и статистике по ним.
Я делаю вью users, которая берет только основные поля из T + pkey
и вью user_stats, которая берет только поля статы из Т + pkey.
Могу я теперь одним селектом получить все данные из T без обращения к самой T, а только через вьюхи? и как? джойнить вьюхи с надеждой, что pg догодается, что джойн не нужен?
wawa, не не... то есть можете конечно испытать пг... для эрудиции.. но если вам одним селектом, нужны все данные из Т... есть большое сомнение - зачем дробить на сущности?
это возможно самый большой самообман вашей ситуации..
Желание дробить таблицу юзеров исходит из наличия в ней полей двух разных групп, каждая из которых обновляется с разной частотой, что например выливается в два поля "updated_at", отвечающих за свою группу полей.
как думаете? как работают суперскоростные key-value?.. или новомодные поколоночные-in-memory-sql-based-решения?
грубо говоря - это и есть 1:1 между колонками.. но рациональность всплывает именно тогда, когда это дает в чем то выигрыш ... к примеру производительность... а рост производительности вполне себе востребован рынком
Ответ Евгений Калибров не лишен смысла.
Я исхожу из совета нормализовывать бд по-максимуму, а уже потом при тесте или росте нагрузки думать об оптимизациях.
Уважаемый mindtester, своим умом блистать я не пытался. Я задал вопрос и ваш коллега Евгений Калибров убедил меня "не бояться джойна". Маловероятно, что PG будет полностью джойнить таблицы. Скорее он это сделает в конце после всех where, order by, limit, что вряд ли окажется узким местом при limit = 50.
Безусловно что-то может пойти не так и я последую вашему совету.
Спасибо, что вызвались мне помочь.
.. оцените трудоемкость к примеру... в первую, вторую.. или в последнюю очередь
Вы так говорите, будто он программу для искусственного интеллекта космического корабля писать собрался... Это же всего лишь один join, какая тут сложность?
Простой
Средний
