Что будет, если убрать из ORM предположение «одна таблица — одна entity»?

[northmule]

С одной стороны выглядит как "сахар" вокруг одной таблицы, с другой возникает мысль как уследить за навозможностью сделать insert одной сущности, когда в таблице есть not null поле и оно существует в другой сущности.
Ведь Виктор Протагонистов мог рассмотреть вариант группировки данных о пользователе по другим таблицам и связывание их через идентификатор с основной таблицей. Тогда бы сущность User, не росла бы так быстро, дополнительные данные можно было добавлять в связанные сущности(таблицы) и получение нужных данных возложить на необходимый QueryBuilder.

[Areso]

ИМХО, решение простое.
У нас есть реальные таблицы, и есть их вьюшки.
Если нам нужен сабсет данных - создаем вьюшку. Если нам нужен join для отображения данных - создаем вьюшку.
Таким же образом можно и права нарезать, если в одну базу ходят несколько сервисов.

[DenisYu-1]

Как мне кажется, вьюшки решают немного другую, хотя и похожую, задачу.

Если нужен удобный read-model: сабсет полей, готовый join, ограничение прав на уровне БД, то вьюхи отлично подходят. Использовать вьюшки прям как сущности приложения пока не доводилось, тут не могу ничего сказать.

[DenisYu-1]

Да, это хорошее замечание.

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

Просто бывают случаи, когда на уровне БД одна таблица уже выбрана осознанно и это нормально, но на уровне кода одна большая User-entity начинает становиться слишком жирной и неудобной для разных модулей.

С insert и NOT NULL ещё интереснее: предусмотрен механизм "валидирования" такой ситуации, чтобы заранее отловить проблему. Но тут как бы от базы не уйдешь – либо нужно эту колонку писать во всех сценариях, либо она всё-таки необязательная :) Ну либо можно сделать read-only модель под сценарий, когда запись не предполагается.

[Zufir]

Таки кто-то вспомнил, что значит I в SOLID?

[lazarus_net]

CREATE TABLE users ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, email VARCHAR(255) NOT NULL, password VARCHAR(255) DEFAULT NULL, stripe_customer_id VARCHAR(255) DEFAULT NULL)

Момент быть для начала выкинем ОРМ и начнем проектировать нормальные - нормализированные БД?

У вас в таблице - stripe_cudtomer_id - уникальный аттрибут, который к user не относится. И должен быть вынесен в отдельную таблицу.

Далее вы предполагаете что у пользователя один email- который not null, и password, который null.

Т.е. вы можете создать пользователя без пароля, а как пароль задавать?

Далее при регистрации пользователь задал email: [e-mail],

Вы добавили пользователя в таблицу, а как будем проверять email? Вдруг это спамер который пытается зарегистрироваться со всеми возможными email? Соответственно вам надо слать запрос на подтверждение email и отслеживать его статус.

Далее Вася Пупкин 100 лет назад зарегистривал домен pupkin.org и email: [e-mail], с которым зарегистрировался в вашей системе.

Потом он забыл пролить домен и домен приобрел Петя Пупкин - его однофамилиц.

И

Недолго думая Петя пытается зарегистрироваться у вас на сервере с email: [e-mail].

Ваш сервис…

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

Вася в восторге …

Все бы это не случилось если бы БД была нормально спроектирована а не код-ферст и т.д. И т.п.

[trawl]

А какие варианты проверки, что пароль сбрасывает Вася, а не Петя?