Yii2 3 таблицы и 2 ActiveRecord?

Question

[Радислав Горбачев]

Доброго времени суток.

Есть 3 таблицы и 2 сущности, одна из таблиц содержит общие свойства, другие 2 содержат подробности каждой сущности.

Вопрос как инстанцировать конкретный класс сущности не стоит, тут можно использовать шаблон single table, а вот как инстанцировать конкретный класс с подробностями без дополнительной связи.

"Теперь перефразирую вопрос правильно как написать свой велосипед с квадратными колёсами"

Жду советов по сабжу, про связь в конкретном классе с классом конкретных подробностей писать не надо сам знаю как это сделать и если ничего интересного не будет, буду реализовывать так.

Скрин псевдо схемы БД:


Вот приблизительно так будет выглядеть схема БД только полей вроде fieldN будет больше какие то поля будут пересекаться какие то нет.

связи:
entities - entity_type1 один к одному
entities - entity_type2 один к одному

поле type в entities как условие выбора конкретной таблицы с подробностями, а соответственно инстанцирование конкретного типа активной записи.

Это похоже на как single table только там одна таблица и множество типов объектов, а тут и типов множество и множество таблиц каждая таблица описывает конкретный тип, но каждый является наследником общего типа.

Comments

[Abdula Magomedov]

Не пользуйтесь запятыми вместо точек.

Answer 1

[tkutru]

Насколько понял из вопроса, у вас связь многие-ко-многим.
Если так, viaTable в помощь
www.yiiframework.com/doc-2.0/yii-db-activequery.ht...

Comments

[Радислав Горбачев]

не совсем, связь один к одному у основной таблицы и у конкретной таблицы подробностей, т.е. основная таблица делит первичный ключ с таблицей подробностей. Мне скорее всего надо копать в сторону популяции из ActiveQuery но что бы не писать свой велосипед ищу готовое решение.

[tkutru]

>>одна из таблиц содержит общие свойства

Если у вас третья таблица хранит не связь, а дублирует данные, то лучше нормализовать отношения. Ну и при прочих равных использовать связи.

>>копать в сторону популяции из ActiveQuery

Вы вроде как отказываетесь от использования связей и джойнов, т.е. что вы там заполните из запроса не вполне понятно.

[Радислав Горбачев]

дополнил вопрос может это поможет понять чего хочется добиться. По сути хочется получить наследование в РСУБД, которое будет прозрачно перетекать в объекты.

[tkutru]

fens ну наследование - термин из ООП, малоприменимо к РБД, ведь наследуются не конкретные реализации, а классы. Ваша табличка entities напоминает справочник, а таблички с подробностями - суть конкретные данные. Вот я бы на вашем месте и использовал их, а если где-то в логике ПО требуется инфа из справочника - подтягивал бы справочник.

[tkutru]

>>а вот как инстанцировать конкретный класс с подробностями без дополнительной связи

Т.е. вкратце - никак, т.к. инфа хранится в разных местах и ее надо связать. И это хорошо, имхо.

[Радислав Горбачев]

Ну мой взгляд решение такое: сделать наследника от ActiveQuery который будет джойнить все таблицы, при вызове метода all(), всех наследников от entities, а метод populate будет вызывать instantiate у главной модели которая будет возвращать по типу конкретный класс а дальше populate запихнет в модель всю строку ну а модель примет только те поля которые ее.

[tkutru]

fens можно так сделать, но зачем? Минусы, навскидку:
а.) Усложняется отладка и поддержка. Если что-то выбирается не так, понять что не так сложнее. Равно как и объяснить суть схемы не-автору решения.
б.) Отказ от джойнов: вы по-сути описали хранимый запрос, "представление". Обычно в РСУБД представления используют чтобы быстро посмотреть нужную инфу в нужном виде. На уровне бизнес логики в yii это решается как раз джойнами, ибо стандартная функциональность. Смысла пилить велосипед я не вижу, имхо.

>>будет вызывать instantiate у главной модели которая будет возвращать по типу конкретный класс а дальше populate запихнет в модель всю строку ну а модель примет только те поля которые ее

Я так понял вы хотите иметь некое представление где будет все обо всем, а при скармливании данных представления какому-то классу этот класс будет решать, какую конкретную модель вернуть. Хоть тресни, я не вижу каких-то супер-преимуществ у этого подхода. Можно так же через UNION объединить инфу из двух табличек и при необходимости подтягивать общее из справочника.

[Радислав Горбачев]

по сути единственное что будет делать переписанная ActiveQuery так это запрашивать у основной модели Entities список классов наследников и выполнять один запрос с джоином всех таблиц подробностей ну, а дальше по накатанной дорожке https://github.com/samdark/yii2-cookbook/blob/mast...
Какое упрощение это даст, для добавления сущности нового типа понадобится только добавить информацию о новом типе в базовый класс и собственно сделать новый класс. Вообще тут еще подсказали другое решение: https://github.com/mdmsoft/yii2-ar-behaviors по аналогии с ним можно просто переписать сеттеры и геттеры для прозрачной передачи параметров к модели подробностей, но тогда в каждой поисковой модели в каждом запросе прийдется руками добавлять какие таблицы джойнить.

Answer 2

[Abdula Magomedov]

Если БД с поддержкой "представлений", думаю можно воспользоваться ими. А так советую только с дополнительной связью. Не понимаю, чем она вам не нравится.