++ only pivot тут

Как вариант - belongsToMany + аксессор который вернет ->first()

А это разве не костыль? Я видел это решение, но оно не кажется мне "правильным".
Или это нормальное решение?

Ну я у себя так делал, тоже была похожая ситуация, вроде нормально 🤔

Если сообщество не считает это костылём, то буду применять.
Спасибо!

Или оформить самозанятость, возможно.

да не. там всё сложнее

ну и вот это вот )

не. всё равно там 50% скидка, но покупать надо то по цене для компаний )) в итоге в минус выйдет

Разраб: *мечтает нагнуть систему и получить халяву*
Система:

)))

просто интересно - зачем такой финт ушами?
какая польза?

Например, использование независимых пакетов, создающих свои миграции и модели, и навешивание на них своих "фич", не затрагивающих функционал пакета.
Чтобы таблица, создаваемая пакетом, оставалась нетронутой. И в случае любого её изменения не возникло никаких конфликтов.

Или в этом случае тоже правильнее внедрить в эту таблицу свои колонки и надеяться на счастливый исход?)

Предполагается, что мы не знаем разработчика пакета, поэтому с таблицей может произойти всё, что угодно :)

Например если пишешь универсальный компонент для магазина, у кого то товар только в одной категории, у кого то в нескольких, проще сразу сделать через пивот и не париться, я в таком кейсе юзал такой финт

Или было пару раз,  в тз четко "1к1", приходит время наполнять - ой, а нам надо 1 ко многим 🤬

в этих 2-х случаях таблица связи не нужна, вроде?
как ее вообще можно втулить в 1-ко-много?

products, categories, category_product

Так суть (в данном случае) компонента в том, что там связи такой нет вообще и не предполагалось. А конкретно в моём проекте она нужна. И есть два варианта: либо я в таблицу пакета полезу и буду её править, либо создам связующую таблицу, где буду хранить эту связь. Но мне-то точно нужно один-к-одному :)

может попробовать по типу belongsToMany, только belongsTo  - в обоих моделях встречно?