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

Question

[PRodion]

В течение недели из-за дня в день переписываю все заново. Застрял на одном месте из-за того, что не получается правильно спроектировать базу данных. Получается так, что вроде все правильно, но когда дело доходит до завершения — упираюсь в неправильную структуру.

Есть 3 таблицы:

Производитель.
— Имеет id и name.

Коллекция.
— Имеет id, manufacturer_id и name.

Цвет.
— Имеет id, collection_id и name.

Логика:

У одного производителя может быть много коллекций. Одна коллекция может принадлежать одному производителю. У коллекции может быть много цветов. Один цвет может принадлежать только одной коллекции.

Сразу скажу, что цвет — это не цвет в привычном понимании, а именно физическая вещь. Если бы это был цвет в привычном понимании, то логично, что один цвет может принадлежать разным коллекциям, но это не тот случай. В нашем случае цвет — это то, что мы используем в качестве имени для безымянного предмета. Коллекции — это не коллекция в понимании Laravel, а просто название таблицы и модели.

— 1. Производитель.
— — 1. Коллекция.
— — — 1. Цвет.
— — 2. Коллекции.
— — — 2. Цвет.
— 2. Производитель.
— — 3. Коллекция.
— — — 3. Цвет.
— — 4. Коллекция.
— — — 4. Цвет.

Мне показалось логичным использование связи hasMany() (один-ко-многим), но все оказалось немного сложнее.

Страницы:

Нам не известны цвета и коллекции. Мы видим только их общее количество.

(Страница производителя)
Производитель — Коллекции — Цвета
Имя_____________2(две)______2(два)

(Страница коллекции)
Производитель — Коллекции — Цвета
Имя_____________Имя_________1(один)
Имя_____________Имя_________1(один)

Когда мы открыли страницу цветов.

(Страница цвета)
Производитель — Коллекции — Цвета
Имя_____________Имя_________Имя
Имя_____________Имя_________Имя

На странице производителя все очень просто и понятно. Мы можем связать модель производителя с моделью коллекции через hasMany() и с моделью цветов через hasManyThrough(). Потом можем посчитать общие количество коллекций и цветов этого производителя с помощью withCount().

На странице коллекции тоже все очень просто. У нас есть обратная связь с моделью производителя belongsTo() и связь с моделью цветов через hasMany(). Мы используем withCount() для подсчёта общего количества цветов принадлежащих этой коллекции.

На странице цветов — тупик. Мы можем получить коллекции к которой принадлежит цвета т.к у нас есть обратная связь с коллекциями через belongsTo(), но у нас нет обратной связи с моделью производителей. В Laravel нет обратной связи для hasManyThrough().

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

Comments

[Антон Р.]

Так а промежуточные связующие таблицы где? Ты смешиваешь сущности делая так: Коллекция.
— Имеет id, manufacturer_id и name.
а это уже не хорошо.
У тебя должна быть промежуточная таблица Manufacturer_collections и там два столбца: manufacturer_id, collection_id, и настроить так что значения могут быть только уникальными, то есть что бы не было две одинаковые пары.

[PRodion]

Антон Р., я ориентируюсь на документацию. У меня связь один ко многим. В документации ни слова о промежуточной таблицы для такой связи. Если бы было многие ко многим, то тогда потребовалась бы промежуточная таблица.

Answer 1

[vism]

Так замечательно задан вопрос, что аж ответить захотелось!

Структура у вас правильная, нсколько я понял из описания.

И поторой такие "цепочки связей" бывают не из 3-х звеньев, а из 10-ти:)
Просто у лараваель есть hasManyThrough через 1 таблицу, но это ни к чему не обязывает. Недавно видел пакет hasManyThrough для 2+ промежуточных таблиц.
Для получения обратных связей по belongTo просто используете так, никакого обратного hasManyThrough тут и ненадо:

$color->collection;
$color->collection->manufacturer;

Answer 2

[Юрий Кулаксыз]

Если я вас правильно понял, у цвета только одна коллекция, а у коллекций всего один производитель. Тогда в модели можно просто сделать метод

return $this->collection()->first()->manufacturer();

Comments

[PRodion]

Юрий Кулаксыз, вы правильно меня поняли. Спасибо за вариант. При таком подходе я опять не зайду в тупик? Следующая проблема, которую я вижу — это чрезмерно большое количество запросов к базе данных. Ваш подход можно будет применить вместе с Eager Loads?

[Юрий Кулаксыз]

PRodion, в тупик не зайдёте, у вас нормальная структура бд. Да, вы сможете вызывать с Eager Loads. Можете ещё попробовать обычными join' ами доставать данные одним запросом, но не думаю, что игра будет стоить свеч

Answer 3

[Иван Мельников]

Самое главное в проектировании БД – это досконально разобраться в предметной области.

Один цвет может принадлежать только одной коллекции.

Странное условие. Неужели две разные коллекции не могут быть синими?

В нашем случае цвет — это то, что мы используем в качестве имени для безымянного предмета

То есть у предмета может быть несколько имен?

Почему бы не сделать отдельно таблицу Коллекция и отдельно таблицу Цвет и связать их таблицей M:N?

Comments

[PRodion]

Иван Мельников, вы либо не читали вопрос. Либо не поняли вопрос. Либо я не понимаю ваш ответ. У меня и так отдельные таблицы для коллекций и цветов. Производитель определяет коллекцию. Коллекция определяет цвет. "Производитель А (клубки)" имеет коллекцию "Коллекцию А (шерстяная)" и "Коллекцию Б (полушерстяная)". "Коллекция А (шерстяная)" имеет синий цвет (клубок) и "Коллекция Б (полушерстяная)" имеет синий цвет (клубок). Вот только в "Коллекцию А (шерстяна)" это синий клубок из шерстяной ткани, а у "Коллекция Б (полушерстяная)" это синий клубок из полушерстяной ткани. И там и там цвет синий, но сами клубки отличаются составом.