Как разграничить хранение данных пользователей?

Question

[junart]

У меня есть тр пользователя , развивающиеся ролями и правами: доктор, поддержка, клиника.
Каждый имеет свой набор полей. Клиника, например, имеет адрес и дату основания. По сути у меня сейчас одна модель данных и таблица Users. Складывать в нее всё поля от разных профилей не вариант.
В тоже время если создавать три отдельные таблицы со своим набором полей.То как потом их сопоставить с моделью users. Чтобы после авторизации знать под кем работаешь. Хотя этим вроде уже занимается механизм полей и прав. Помогите пожалуйста разобраться, сейчас мешанина.

Comments

[Adamos]

Доктор, поддержка и клиника - это не три пользователя, а три группы пользователей.
Ваш К.О.

[junart]

Adamos, где и как хранить информацию о каждом? Например после регистрации

[Adamos]

junart, там, где вам удобно будет с ней работать.

[junart]

Adamos, удобно через объект модели юзера, но класть в таблицу все поля от каждого типа пользователя не очень хочется

[Дмитрий]

junart, поля то какие? И как используются?

[Adamos]

junart, через модель юзера - проще, но не удобнее. Раздутая без необходимости модель - это неудобно.
Распишите использование этой информации, это поможет понять, как ее надо будет читать и искать. Как хранить - решается в последнюю очередь, после этого понимания.

[mayton2019]

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

Если безопасность - то тогда надо завести в каждой таблице только одно поле user_role и писать туда владельца. И при доступе соотв фильтровать.

[junart]

mayton2019, вы меня поняли правильно. Создавая отдельные модели для каждого типа пользователя я сталкиваюсь с проблемой как эти модели связать с текущим авторизованным пользователем. Чтобы всегда иметь возможность эти поля отобразить, например, если авторизован как клиника, должно быть поле Дата основание.

[junart]

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

[junart]

junart, а как подставлять разные модели тогда если юзер авторизован?

[mayton2019]

junart, почитайте про Row level security. Официально вроде как MySQL это не поддерживает но может есть какие-то фреймворки или наработки.

[Дмитрий]

junart, ещё раз какие поля и как они используются. В случае если это куча мелких текстовых полей которые не используются в выборке - сделайте data типом json.

[ThunderCat]

Adamos,

Доктор, поддержка и клиника - это не три пользователя, а три группы пользователей.

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

Answer 1

[Vfreelance]

доктор, поддержка, клиника - это роли. а данные можно хранить в доп. таблицах. например, doctor_profiles, support_profiles. в них есть user_id - связь с users. тогда доступ можно так $user->doctorProfile, $user->supportProfile. Можно создать https://laravel.com/docs/9.x/eloquent-relationship... или просто отдельно связь $user->profile где внутри if/else hasOne в зависимоти от role.

Answer 2

[ThunderCat]

Каждый имеет свой набор полей. Клиника, например, имеет адрес и дату основания.

Мне кажется вы как-то не так пользователей определяете, клиника как пользователь не кажется логичным утверждением. Пользователь - сущность имеющая общие атрибуты - логин, пароль, опционально дату регистрации и еще несколько признаков присущим людям/иным разумным. В частности, логинится не здание фирмы и не юридичкское лицо в виде учредительных документов, а конкретный Федор Пупкин из клиники "Веселая челюсть". И связь Федора с клиникой через один ко многим (либо многие ко многим, в зависимости от сложности возможных пересечений) видится более адекватной структурой, как минимум по тому что не только Федор может управлять действиями от лица клиники, а еще например бухгалтер Василиса Андреевна. Проблема в том что у вас юзерами стали объекты, по дефолту к ним не относящиеся. Как только вы отделите мух от котлет, все встанет на свои места, в том числе через роли, так как к клиникам будут иметь доступ только роли работников клиники.

Comments

[Adamos]

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

Answer 3

[Akina]

На уровне СУБД я бы не заморачивался и использовал разреженную таблицу. Т.е. таблица содержит поля, необходимые для объекта любого типа, но заполнены только те, что относятся к текущему типу, а остальные NULL.

Но вот насколько это реализуемо в Laravel - даже предсказать не берусь...