Как мне кажется, вьюшки решают немного другую, хотя и похожую, задачу.
Если нужен удобный read-model: сабсет полей, готовый join, ограничение прав на уровне БД, то вьюхи отлично подходят. Использовать вьюшки прям как сущности приложения пока не доводилось, тут не могу ничего сказать.
Если данные действительно имеют разный жизненный цикл, разные правила владения и независимо развиваются, то вынесение их в отдельные таблицы и связи по user_id – лучшее решение.
Просто бывают случаи, когда на уровне БД одна таблица уже выбрана осознанно и это нормально, но на уровне кода одна большая User-entity начинает становиться слишком жирной и неудобной для разных модулей.
С insert и NOT NULL ещё интереснее: предусмотрен механизм "валидирования" такой ситуации, чтобы заранее отловить проблему. Но тут как бы от базы не уйдешь – либо нужно эту колонку писать во всех сценариях, либо она всё-таки необязательная :) Ну либо можно сделать read-only модель под сценарий, когда запись не предполагается.
Как мне кажется, вьюшки решают немного другую, хотя и похожую, задачу.
Если нужен удобный read-model: сабсет полей, готовый join, ограничение прав на уровне БД, то вьюхи отлично подходят. Использовать вьюшки прям как сущности приложения пока не доводилось, тут не могу ничего сказать.
Да, это хорошее замечание.
Если данные действительно имеют разный жизненный цикл, разные правила владения и независимо развиваются, то вынесение их в отдельные таблицы и связи по
user_id– лучшее решение.Просто бывают случаи, когда на уровне БД одна таблица уже выбрана осознанно и это нормально, но на уровне кода одна большая
User-entity начинает становиться слишком жирной и неудобной для разных модулей.С
insertиNOT NULLещё интереснее: предусмотрен механизм "валидирования" такой ситуации, чтобы заранее отловить проблему. Но тут как бы от базы не уйдешь – либо нужно эту колонку писать во всех сценариях, либо она всё-таки необязательная :) Ну либо можно сделать read-only модель под сценарий, когда запись не предполагается.