@DrBerrymore

Doctrine inheritance или что-то другое?

Необходимо в системе сделать аккаунты для ведения мини бухгалтерского учета. Проблема в том, что эти аккаунты (на данный момент) бывают 4-х разных типов: внешний, системный, пользовательский, корпоративный.

Внешний и системный ничем не отличаются и содержат в себе только основные свойства аккаунта: id, currency, value
Пользовательский и корпоративный помимо основных свойств должны быть как-то связаны с соответствующими сущностями: пользователь и компания.

Какой самый оптимальный способ реализовать это через Доктрину или в целом с точки зрения DBA ?

1. Я попробовал поместить все аккаунты в одну таблицу, прибегнув к использованию STI (Doctrine: Single Table Inheritance). Но у такого способа есть минус -- аккаунты будут всегда eager-лоадиться в сущности, которые с ними связаны. То есть, если я получу пользователя, то аккаунт в нем уже будет содержаться, значит Doctrine выполняет дополнительный запрос.

2. Еще пробовал вариант использовать many-to-many связи c уникальными ключами, в таком случае фактически получается one-to-one, но через промежуточную (pivot) таблицу. В таком случае вроде бы все работает, но поле $account у юзера теперь не просто Account, а ArrayCollection. Хотя в этой коллекции фактически всегда будет храниться один объект Account.

Все это про аккаунты в одной таблице accounts. Можно, конечно, сделать MappedSuperClass и сделать N таблиц с аккаунтами, но тогда получится много таблиц с около-одинаковой структурой. ИМХО это выглядит не очень, но может так и надо сделать? Интересны ваши мнения
  • Вопрос задан
  • 349 просмотров
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы