Laravel как создать сразу две взаимосвязанных модели?

Question

[Александр Аблизин]

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

$user = new User; // id|space_id|name
$space = new Space; // id|user_id

$user->name = $name;
$user->save();
$space->user_id = $user->id;
$space->save();
$user = User::find($user->id);
$user->space_id = $space->id;
$user->save();

Answer 1

[Алексей Уколов]

Раз у вас денормализация данных, то никуда не уйти от тройного сохранения.
Вы уверены, что эта денормализация вам нужна, вы сделали её осознанно?
Если вы храните ссылки на другую сущность в обеих моделях просто по незнанию, то не делайте этого и проблема возникать не будет. Я бы хранил в Space ссылку на User и всё, потому что, скорее всего, Space без User быть не может, а наоборот - вполне.

Если у вас в моделях корректно указаны связи, можно переписать вот так, но общий смысл от этого не поменяется:

$user = new User; // id|space_id|name
$space = new Space; // id|user_id

$user->name = $name;
$user->save();

$space->user->associate($user);
$space->save();

$user->space->associate($space);
$user->save();

Comments

[Александр Аблизин]

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

[Александр Аблизин]

Т.е. получается в момент создания User должно появится и Space и тут-же User должен привязаться к своему же Space и в самой Space должно быть указано, кто в нём главный.

[Алексей Уколов]

В таком случае, я бы на вашем месте из Пользователя упоминание Области убрал полностью, а в Области создал поле owner_id или manager_id, в зависимости от контекста (user_id слишком общее название). И отдельно добавил бы таблицу сопряжения Пользователей и Областей. Можно в Области вообще не указывать владельца, если в таблице сопряжений добавить поле role.

[Александр Аблизин]

Алексей Уколов: Идея отличная, но не появится ли в результате из за pivot-таблицы (и сама таблица будет увесистая) куча дополнительного кода и как следствие дополнительная нагрузка на бд, ведь вот такое тройное сохранение используется только один раз при создании, в остальных случаях используются отношения.

[Алексей Уколов]

"Дополнительный" код достаточно грамотно организовать, нагрузки на БД не будет. Зато вы получите возможность закреплять за одним пользователем несколько областей (суперадмин какой-нибудь), за одной областью несколько пользователей и ввести систему ролей. В перспективе это значительно важнее, чем пара методов для создания пользователей.

[Александр Аблизин]

Алексей Уколов: Спасибо, но тут есть момент, у области должен быть только один owner и не при каких обстоятельствах не должно быть более одного, а для суперадминов существует ещё одна таблица supervisors где пользователям даётся разрешение с привязкой к группе, пока этого достаточно.

[Алексей Уколов]

> у области должен быть только один owner и не при каких обстоятельствах не должно быть более одного
Это сейчас так, а потом правила могут измениться :)
Либо сделайте роль в таблице сопряжения и проверяйте уникальность владельца на уровне приложения (гибко, но менее надёжно).
Либо сделайте в таблице областей owner_id и отдельную таблицу сопряжения без ролей (надёжнее и всегда можно сконвертироваться в первый вариант с ролями).

Answer 2

[Антон Сашнин]

В модели User:

public function space()
{
return $this->hasOne('App\Space');
}

+ в миграциях указываешь связи.

Comments

[Алексей Уколов]

Каким образом это решает задачу автора?

[Антон Сашнин]

Алексей Уколов: намек на связи, не?

[Алексей Уколов]

У него же проблема не в связях, а в денормализации из-за которой приходится делать три запроса при создании сущностей. Какой синтаксис создания используется неважно - проблему это не решает.

[Антон Сашнин]

> а в денормализации
Тут все гораздо хуже, зачем в модели User храниться ссылка на Space, а в Space на User?

[Алексей Уколов]

Ну так это и есть денормализация. Но, судя по тому, что пишет Александр Аблизин, у него денормализация не ради увеличения производительности, а из-за кривой схемы данных.

[Антон Сашнин]

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

[Антон Сашнин]

> $space->user->associate($user);
Советую не использовать в контроллерах, все-равно будет каша.

[Александр Аблизин]

antonsash: Да нет каши, всё работает в виде "proof of concept" просто пришло время править костыли, а опыта не хватает.

[Александр Аблизин]

Алексей Уколов: в том числе и ради производительности, это CRM и бд у неё достаточно узкое место, и таблица с пользователями единственная которая не поддаётся шардингу, шардинг как раз строится на пространствах (и подпространствах)

[Алексей Уколов]

В CRM очень часто требуется гибкость, особенно в плане ролей. И вы, занимаясь преждевременной оптимизацией, пилите ногу, на которой стоите (вот так изящно я соединил две пословицы, да). Сделайте расширяемую архитектуру, а оптимизацией занимайтесь только тогда, когда в ней реально возникнет необходимость и в минимально возможном объёме. Потому что дописывать эту CRM вам ещё много лет и вставляя такие костыли в самое ядро системы вы копаете себе яму.

[Александр Аблизин]

Алексей Уколов: Да она уже работает, гибкости хватает (пока), просто хочется некоторые моменты сделать правильно, а не "лишь бы работало", хотя повторюсь всё работает. Так что обе ноги я себе уже отпилил)) Теперь вот надо либо учится бегать на культяпках, либо всё заново собирать, я к сожалению не опытен в разработке проектов таких масштабов, а времени на опыт катастрофически не хватает.

[Алексей Уколов]

В таком случае, либо оставьте всё, как есть, либо сделайте так, как я предложил в комментариях к своему ответу. Промежуточные варианты - это мутный компромисс, от которого толку не будет.

[Александр Аблизин]

Алексей Уколов: Большое спасибо за направление мысли, в любом случае мои страхи про производительность неуместны ибо всё тестируется, а вот такую архитектуру как сейчас показывать стыдно.