What is the best way to implement such an architecture?

Question

Software design

Hello.
I'm thinking about how best to implement the following architecture (previously, projects did not have so many different roles)
I want to use Laravel as a framework.
We have an admin, moderator, curator and client in the system.
The moderator is the same admin with fewer rights
. The curator monitors the client's progress in training.
The client has his own attributes (for example, where he studied, etc.), the curator has his own (achievements and other things that the client does not have).
The question naturally arises, how best to implement this architecturally?
Make several models - (Client, Curator, Moderator, Admin) and each has its own table with data, of course, when logging in, you will need to access different tables with a login and password search. But the advantage is that the attributes don't get mixed up.
The second option is the User model and, depending on the role, a 1 to 1 relationship with a table that has additional attributes.
In fact, in this way we will use 1 model for queries.
I can’t immediately understand in advance which of the approaches is better, so I turn to senior comrades in the shop for advice.
PS Another point - if you implement the first format with 4 models, then how to make a single authorization for all within the framework of the standard Laravel authentication? ..

Answer 1

Roles are sets (more precisely, "trees" of sets) containing users.
I paint in detail on an example :
There is a user User1, he has the role of Admin and the role of Curator.
Those. he has 2 menu items in his personal account: Administration and Supervision.
Everything in the database is linked only through the ID-shnik of this user (roles and role fields, etc.).

Answer 2

emnip in laravel already has a ready-made RBAC. Or you can unscrew from symphony / zend.
On the topic - of course, no additional entities are needed in the user's stern, they differ only in the associated property of the role.

Answer 3

On idea users - separately, roles - separately.
And one user can have multiple roles, i.e. between users and roles d.b. link table.
And one-to-many relationships.
Total we have three tables: users, roles, connections.

Answer 4

Now I'm doing a project with a similar structure.
Through trial and error :) I found out that it is best to do this:
1. All fields of all roles are dumped into one table (the same fields are not duplicated) and made nullable
a) either in users (it turns out a little sloppy);
b) either in profiles (1:1 ratio with users), just to separate cutlets from flies.
2. In the source code, NOT ROLES are checked, but permissions, and for each profile property (study, achievements) - its own permission.
This will allow you at any time to add permission, for example, to "achievements" in the role of the client and he will have the corresponding form elements, views, etc.
There is also one subtlety here: if the administrator's role allows him to edit other people's profiles, then it is advisable to show him only those fields that are allowed for a specific user (whom the administrator edits). This is not a problem if your RBAC module allows callbacks to check permissions.
Here is a module with custom callbacks: h-rbac
And an article about it: Laravel 5. Hierarchical RBAC for the smallest