Несколько типов аккаунтов, как лучше организовать на уровне таблицы/миграций?

Question

[Sanjar Tolibjonov]

У меня есть приложение, куда будут регаться разного типа аккаунты.
Три основных типа есть — заказчик, исполнитель, админ.

Заказчик может создать у себя аккаунт для своего менеджера. Просто покажу структуру примерную:

1. Заказчик;
1. Менеджер;
2. Исполнитель
3. Администратор
1. Контент-менеджер
2. Аудитор

Главных типов аккаунтов три, некоторые из них могут создавать другие аккаунты.
Тут сразу ясно что нужны пермишены и роли, я буду использовать laravel spatie, доступы можно делать по ролям, пермишенам, проблема не в этом.

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

Не делать же разные таблицы вроде AdminUser, ManagerUser, и прочее.

Comments

[Antonio Solo]

тут вопрос немого "глубже"
1) возможность совмещения ролей (или наличия каких-то то промежуточных, пересекающихся ролей)
2) разграничение доступа к определенным полям в зависимости от роли. (то есть например к балансу заказчика может иметь доступ заказчик только на просмотр и администратор на редактирование, а cвоему к полю "служебные заметки" заказчик доступа не имеет, зато оно доступно для редактирования менеджеру.

и модель данных уже следует выбирать исходя из ответа на эти вопросы.

то есть вроде "правильное" разбиение на "profile_admin, profile_manager" становится очень неудобной, если ваш пользователь имеет одновременно права и менеджера и админа.

Answer 1

[Lander]

Я, в подобных случаях, в таблицу user выношу только то что касается авторизации. А все дополнительные поля выношу в таблицы profile_*. В вашем случае profile_admin, profile_manager и т. д.

Answer 2

[dblearn94]

Sanjar Tolibjonov использовать "табличный ввод" (не знаю как он правильно называется)
Суть такова, что у вас есть отдельная таблица где хранятся поля и значения, которые привязаны к профилю, и вам не нужно добавлять кучу полей в конкретно таблицу с профилями.

типа:
profile_setting:
profile_id | name | value

ну и соответственно строите связи, и все, проблема решена

Comments

[Sanjar Tolibjonov]

Т.е правильно ли понял, что я могу сейчас сделать базовый класс User где общие для всех аккаунтов поля (все что для авторизации и прочего), и потом если понадобится расширение, просто сделать таблицу profile_setting и по ней добавлять нужные поля?
Именно в плане расширяемости.

[Антон Иванов]

Sanjar Tolibjonov, да, правильно

[dblearn94]

Sanjar Tolibjonov, да, это будет правильным решением

[JhaoDa]

Правильно это называется EAV.

Answer 3

[Олег Фролов]

Используйте MongoDb и будет вам счастье.

Comments

[dblearn94]

Олег Фролов зачем ему тут монго ?