Как в laravel создать связь модель к таблице?

Question

[Виктор]

Есть модель и таблица Product с полями

id
title

и таблица с ссылками Photo

id
product_id  //связь с таблицей Product 
url

У одного Product может быть несколько Photo. Какую связь создать в модели к таблице? Или нужно создавать модель Photo и промежуточную таблицу Product_Photo_Relations (product_id , photo_id)?

Comments

[JhaoDa]

А как ты пробовал? Если никак, то смысл тебе помогать?

Answer 1

[ThunderCat]

У одного Product может быть несколько Photo. Какую связь создать в модели к таблице?

Вроде из определения должно быть очевидно. У продакта хэз мэни фото, у фото можно (но не обязательно) белонгс ту продакт.

Comments

[Виктор]

Тоесть нужно создавать модель Photo?

[ThunderCat]

Виктор, Это сущность, имеет все признаки таковой, включая необходимость CRUD, соответственно модель нужна.

[Виктор]

В Product?

public function photos(): \Illuminate\Database\Eloquent\Relations\HasMany
    {
        return $this->hasMany(Photo::class, 'product_id' ,  'id');
    }

Еще такой вопрос, какой метод использовать при добавлении и обновлении Product
например

$product =  Product::create([
'title' => 'custom title'
]);
$product->photos-> ?

[ThunderCat]

Виктор, $product->photos-> ?Емнип прямого добавления через связь там нету, тем более что в результате в $product->photos у вас коллекция, а не объект. С фото работаете как с отдельными сущностями (собсно для этого они и вынесены в отдельную таблицу и модель).

$product =  Product::create([
'title' => 'custom title'
]);
foreach ($images as $image)
Image::create([
'product_id' => $product->id,
'url' => $image['url'],
]);

[Виктор]

ThunderCat, Ок, спасибо за помощь!

[Сергей delphinpro]

Виктор,

$product =  Product::create([
  'title' => 'custom title'
]);
$product->photos()->create(['url' => $image['url']])

Тогда не нужно указывать product_id при создании. Связь автоматически проставится.

[Виктор]

спасибо

Answer 2

[Sanes]

Если фото принадлежит только одному продукту, то один ко многим. А можно просто в таблице products доп поле json хранить пути до фото.

Comments

[ThunderCat]

А можно просто в доп поле json хранить пути до фото.

Не можно.

[Sanes]

ThunderCat, можно

[Sanes]

ThunderCat, этим ребятам скажи, что так нельзя.

[ThunderCat]

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

[ThunderCat]

Sanes, Ребята, так нельзя.

[ThunderCat]

Sanes, Так то и в вояджере картинки в жсоне хранятся, что не говорит о качестве решения, а говорит о кривой попытке универсализации.

[Sanes]

ThunderCat, лишь бы что-нибудь ляпнуть? Это нормальная практика.

[ThunderCat]

Sanes,

Это нормальная практика.

Нет, это жестко связывает 2 независимые сущности, картинку и объект. Решение такое же "нормальное", как хранение списка категорий в текстовом поле объекта айдишниками через запятую. Для кода уровня вордпресс может и норма, для приличного проекта стыдоба.

[Sanes]

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

[ThunderCat]

Sanes, Вопрос не в достаточности, а в подходе. Когда вы создаете "поле под картинки", вы задаете будущую архитектуру, которой будут следовать все дальнейшие изменения в проекте. Допустим, через год вам понадобится добавить видео и, например, мануалы/инструкции/драйвера для каких-то товаров.

С вашим подходом надо будет создать еще надцать полей, на каждый тип сущности в таблице продакт. Кроме того, в самом объекте придется использовать дополнительные манипуляции по извлечению этих сущностей из полей и раскодировкой из жсона, и все это руками, плюс надо помнить что там как записано, потому что кроме как в рандомных местах кода нигде формат записи/чтения не записан. В противовес аккуратного $product->photos и четкого списка полей в бд/миграции.

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

Молчу о том что сами связанные сущности могут иметь какие-то вынесенные в отдельные связи свойства, и тогда вы получаете дополнительный асспэйн при работе с ними в формате отдельного поля...

Ты хранишь в одной таблице все данные, соответственно нагрузка минимальная

О, да, точно, "аптимизация" же, экономика спичек должна быть экономной и вот это все... Ну какая там нагрузка на джоинах двух табличек? Что за погоня за ускользающими микросекундами? С таким подходом проще вообще все в одну таблицу с 50 полями свести и все, профит, все летает (спойлер: нет)... И сложности с какими то там сущностями мутными отпадают...

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