И для всех разных типов существует единый список Экшинов одинаково применимый для всех типов обьектов,сущностей?

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

Скорее всего нет, пока не знаю, я в процессе придумывания)

Я бы не абстрагировался раньше времени, по сколько не известны все требования. А потом появятся еще новые.

То что посоветовал Илья(Полиморфные связи), это как раз то что я искал.  Надо придумать как грамотно их обрабатывать. Пока нагуглил, что в Laravel из коробки идет система работы с полморфными связями, сейчас смотрю как они сделали.

Да, да, согласен, но я ведь как раз сейчас прикидываю что как будет, по этому это в рамках ресерча)

Будущие требования и запросы не предскажешь.
На сколько просто можно будет мигрировать таблицы с полиморфными связями?

https://www.slideshare.net/mobile/billkarwin/sql-antipatterns-strike-back
Четвертый слайд)

))

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

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

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

У вас хвост машет собакой

Вы пытаетесь описать в БД модель пермишнов, не имея (или не оглашая) картины как это будет

с вероятностью 95% полиморфные связи - тупиковый путь

Я вот написал и думаю, если на самом деле составить таблицу со всеми редактируемыми Entity и полям этих Entity присвоить nullable=true, потом при добавлении новой сущности в эту таблицу, в старых записях она будет просто null и это проблемы не вызовет.

Вот по-моему, хороший тред-обсуждение. С практическим применением на длительном промежутке времени (в пару лет) полиморфные связи https://laracasts.com/discuss/channels/eloquent/polymorphism-why-should-i-violate-database-design?page=1

поздравляю, вы начинаете изобретать nosql :)

а потом пойдут частичные индексы и погнали... :)

Спасибо, кстати, Илья, что предложили не обычное решение. Об антипаттернах тоже полезно знать.

😁
https://docs.gitlab.com/ee/development/polymorphic_associations.html