Как реализовать такую архитектуру на Eloquent Laravel?

@Haybulla · Регистрация: 24.01.2013

Студворк — интернет-сервис помощи студентам

Есть проект, в нем такие роли - админ, врач, клиент. У клиента своя анкета, у врача своя. Про RBAC вопросов не задаю, тут мы просто раскидаем на users, roles и role_user

Главный вопрос - если мы врачей и клиентов храним в одной таблице, как лучше хранить их анкеты?

Ведь у врача есть обязательное поле - специализация, например. У клиента его нет, зато есть свое специальное поле, к примеру, это хронические болезни.

Какие варианты вижу я:

1. Все затолкать в одну таблицу (users), нужное подтягивать в зависимости от ситуации. Минус в том, что это бардак в чистом виде - одна таблица двоих еще вместит, а что если там 3-4-5 ролей? Там уже будет хлам.

2. Сделать поле анкета json-ом. Тут тебе и компактность, и нет смешения, но json достаточно недавно в sql для меня, не знаю точно, где его юзать. Да и поиск становится чуть замороченнее.

3. Просто сделать users как базовая модель, а от нее наследовать другие модели - clients и doctors. Тут надо разобраться - как такое сделать и как решать вопрос с авторизацией и как внутри связи устроены? Если этот вариант годный, буду его копать.

4. Увести профили в отдельные таблицы, например, client_profiles и doctor_profiles. Но как тогда корректно прокинуть связь так, чтобы у докторов не было client_profiles (пусть и null'евого), а у клиентов doctor_profiles?..

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

Короче, понимаю, что варианты есть разные, есть мною не описанные, но хотелось бы понять, какие в этом вопросе best practics?

@tarasalk · 26.09.2019, 14:41

Они все нормальные надо смотреть на задачу.
1) Не подойдет если у роли много специфичных полей.
2) С json надо смотреть на возможности БД. Тут могут быть проблемы с сортировкой, индексами, внешними ключами итп.
3) Вот это точно не надо. Должно быть общая таблица вида id, login, password.
4) Хороший вариант если не нужно динамически создавать роли. Просто добавляем в users поле profile_id и в зависимости от роли стучим в соответствующую таблицу. Если у юзера много ролей, то profile_id добавляем в role_user.
5) Этот вариант хорош если нужно возможность динамически добавлять атрибуты.

Думаю вам больше подойдет вариант 4.

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Access VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

@Haybulla 0 / 0 / 0 Регистрация: 24.01.2013 Сообщений: 27

	Как реализовать такую архитектуру на Eloquent Laravel? 25.09.2019, 23:56. Показов 1327. Ответов 1 Метки eloquent, laravel (Все метки) Есть проект, в нем такие роли - админ, врач, клиент. У клиента своя анкета, у врача своя. Про RBAC вопросов не задаю, тут мы просто раскидаем на users, roles и role_user Главный вопрос - если мы врачей и клиентов храним в одной таблице, как лучше хранить их анкеты? Ведь у врача есть обязательное поле - *специализация, например. У клиента его нет, зато есть свое специальное поле, к примеру, это хронические болезни. Какие варианты вижу я: 1. Все затолкать в одну таблицу (users), нужное подтягивать в зависимости от ситуации. Минус в том, что это бардак в чистом виде - одна таблица двоих еще вместит, а что если там 3-4-5 ролей? Там уже будет хлам. 2. Сделать поле анкета json-ом. Тут тебе и компактность, и нет смешения, но json* достаточно недавно в sql для меня, не знаю точно, где его юзать. Да и поиск становится чуть замороченнее. 3. Просто сделать users как базовая модель, а от нее наследовать другие модели - clients и doctors. Тут надо разобраться - как такое сделать и как решать вопрос с авторизацией и как внутри связи устроены? Если этот вариант годный, буду его копать. 4. Увести профили в отдельные таблицы, например, client_profiles и doctor_profiles. Но как тогда корректно прокинуть связь так, чтобы у докторов не было client_profiles (пусть и null'евого), а у клиентов doctor_profiles?.. 5. Вышеописанное еще можно сделать так - сделать таблицу profile_attributes, и построчно выставлять соответствие между атрибутом профайла и значением для каждого конкретного юзера - клиента или доктора, не важно. Короче, понимаю, что варианты есть разные, есть мною не описанные, но хотелось бы понять, какие в этом вопросе best practics? 0

@tarasalk 1992 / 1216 / 440 Регистрация: 13.06.2013 Сообщений: 4,115
	26.09.2019, 14:41
	Они все нормальные надо смотреть на задачу. 1) Не подойдет если у роли много специфичных полей. 2) С json надо смотреть на возможности БД. Тут могут быть проблемы с сортировкой, индексами, внешними ключами итп. 3) Вот это точно не надо. Должно быть общая таблица вида id, login, password. 4) Хороший вариант если не нужно динамически создавать роли. Просто добавляем в users поле profile_id и в зависимости от роли стучим в соответствующую таблицу. Если у юзера много ролей, то profile_id добавляем в role_user. 5) Этот вариант хорош если нужно возможность динамически добавлять атрибуты. Думаю вам больше подойдет вариант 4. 1

Опции темы