ну тут навенрное как-то через Category::with('parent') можно такое получить

С чего ларе думать?

Это же не ИИ

хотя даже так нельзя

это запрос к таблице

Проще parent оставить. Без подписи id

Чтобы Eloquent пытался что-то подключить, то ему нужно сказать это. Но для начала создать связи нужные

не проще. уж лучше связь единообразно называть
лучше вообще parent_category_id

или вообще заюзать пакет для nested sets если вложенность категорий не строго определена

И наплевать на принятые сообществом правила именования 😏

parent_id прокатит

Оказывается в том году я уже так делал

Прокатит

Если правильно связь указать

просто как он среагирует если например будет
public function children() {
   return $this->hasMany('Category','parent_id');
}

По идеи нормально должен

Добрый вечер, подскажите или дайте совет кто-нибудь по части проектирования базы данных: делаю пет проджект – биллинговая платформа с услугами, управлением услуг, инвойсами и тд

Вопрос по части услуг: в проекте планируется возможность создавать свои собственные услуги, а так же заранее определенные услуги, такие как vps, domain, vds

Пример услуг:

VPS: VPS Micro | 1 CPU | 512mb ram | 20 SSD | trial days |  daily | monthly | annually | и так далее перечисления возможных периодов оплаты

Но так же может быть услуга просто "Администрирование", которой нужно только поле "Наименование услуги" и стоимость одного из периодов

Думал сначала проектировать как "конструктор", соответственно было нечто подобное:

services: name | code | icon | trial | daily | monthly | и тд периоды
service_values: service_id | param | value

Но получается очень рутинная жопа т.к. заранее ничего не определено и каждый параметр нужно проверять на существование

Единственный вариант, который мне приходит на ум, это сделать единую таблицу services и добавить ей полиморфную связь many to many
Получится нечто вроде:
services: id | name | code | icon | trial | daily | monthly | и тд периоды
serviceable: id | serviceable_id | serviceable_type
vps: core | ram | ssd | active

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

может почитать про EAV?

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

Ребят чем может быть вызвана эта ошибка?