How to implement such an architecture on Eloquent laravel?

Question

Laravel

I recently asked a similar question, but of a general nature and more about RBAC. I dealt with that question relatively, but the other one remained, and I ask it.
I remember the intro.
There is a project, in it such roles - the administrator, the doctor, the client. The client has his own profile, the doctor has his own.
The main question - if we store doctors and clients in one table, how best to store their profiles?
After all, a doctor has a mandatory field - specialization , for example. The client does not have it, but he has his own special field, for example, these are chronic diseases.
What options do I see:
1. Push everything into one table ( users), you need to tighten depending on the situation. The downside is that this is a mess in its purest form - one table of two will still fit, but what if there are 3-4-5 roles? There will already be rubbish.
2. Make the form field json . Here you have both compactness and no confusion, but json is quite recent in sql for me, I don’t know exactly where to use it. Yes, and the search becomes a little more confused.
3. Just make users as the base model, and other models - clients and doctors - inherit from it. Here we need to figure out - how to do this and how to solve the issue with authorization and how are the connections arranged inside? If this option is suitable, I will dig it.
4. Move profiles to separate tables , for example, client_profiles and doctor_profiles. But then how to correctly connect the connection so that doctors do not have client_profiles (albeit null), and clients do not have
doctor_profiles ? for each specific user - a client or a doctor, it does not matter.
In short, I understand that there are different options, there are those that I have not described, but I would like to understand what are the best practices in this matter?

Answer 1

Subscribed to the question, but I'll say for sure that:
1. null'and unnecessary fields, they do not take up much space. There will be rubbish in the table, but if you break one table into several models in the code, it will be better and calmer.
2. json - not really an option, only if you somehow abstract it and you will shove everything from json back into attributes, so that it would be convenient to work with it in the code. But this is also an option.
3. if you use uuid and morph of the connection without foreign keys - yes, as an option
4. do not create profiles who do not need it and that's it)
5. no, crap. Even worse than the second option.
In this particular case, I would choose between options 1 and 3, because attaching the "specialization" primitive to some separate entity is such a pleasure. The first one is not as bad as it seems, and the third one is theoretically more difficult to work with, although this is not a bad idea.

Answer 2

I'm up for 4. HasOne relation and user_id field in each table. When registering, the user chooses that he is a doctor and you create an entry in the doctor_profile. Pull up through with. It is convenient because it is simple and clear)

Answer 3

Option 4 of the proposed most suggests itself.
But there is another 6 option that is more interesting, but more complicated, create 2 tables
Table attributes
id
name
role_id
Table attribute_values
​​attribute_id
user_id
value

Answer 4

Tables:
# users
- id
- login
- password
- role
# doctors
- id
- user_id
- specialism
# pacients
- id
- user_id
- complaint
User model:

class User extends Eloquent
{
    /**
     * @return \Illuminate\Database\Eloquent\Relations\HasOne
     */
    public function profile()
    {
        if ($this->role == 'doctor') {
            return $this->hasOne('App\Doctor', 'user_id', 'id')
                ->withDefault();
        }
        
        if ($this->role == 'pacient') {
            return $this->hasOne('App\Pacient', 'user_id', 'id')
                ->withDefault();
        }
        
        return null;
    }
}

Answer 5

I'm leaning towards option 4.
but how to organize the link options:
1)
user.doc_profile_id -> doc_profile.id
user.pat_profile_id -> pat_profile.id
2)
user.type=doc user.profile_id -> doc_profile.id
user.type=pat user.profile_id -> pat_profile.id
3)
doc_profile.user_id -> user.id
pat_profile.user_id -> user.id

Answer 6

You need to put not only the profiles in separate tables, but also the types of users.
Total tables
users
doctors
clients
admins
The tables of doctors and clients refer to users. In users, general info, in doctors, the id from the user and all the necessary fields for the questionnaire. Also with clients. Admins may not be tied to users, this is how the requirements are organized.

Answer 7

I work with option 3, it's very convenient, each class model conveniently stores the necessary methods for the user role. No extra tables, only users, user_data, formrequest validation - can be divided depending on the role, as well as the set of accepted fields. I think it's perfect.)