Level 15
Hi mbpp
You would normally just have one 'users' table:
users:
- id;
- role_id;
- first_name
- etc
You then reference the role in a separate 'roles' table.
roles:
- id;
- role_type // employer or job_seeker
1 like
May 3, 2017
4
Level 3
Roles and user types
Hi there guys, i need some advice, i notice after some time, learning more about laravel and application development i feel maybe my app that im building is not being done the right way, so hope for someone advice me about it.
Baically the app im building is a job portal, and in this job portal i have 2 types of users (employer, jobseeker).
In my db i build the tables something like:
users:
- id;
- name;
- surname;
- password;
- account_type_id (job_seeker, employer);
employers:
- user_id;
- more detailed information columns...
job_seekers:
- user_id;
- more detailed information columns...
This it the structure that i been building my application, but after looking in some videos i hear people saying thats not the Laravel way to be done, since roles and user types or completelly different things and in user_types in my case employers and job_seekers should be in one table with there own password, email, etc information from the users table.
What your opinion regarding with it?
Level 3
Hello @Screenbeetle so basically with how i did it, is not completelly wrong right?
Level 15
so basically with how i did it, is not completelly wrong right?
You can certainly do it your way. You just have to be careful not to add unnecessary complexity.
If you have many fields that employers and job_seekers don't share then separate tables can make sense. But in this situation I would ask first - can you have one users table (for all shared employer and job_seeker data) but then think of the other tables as holders for extra data that you relate to a user. This is often more flexible.
For example: I have a project with various admin users and then a 'member' user (like a customer). Member's have to fill in a questionnaire when they join the site. This questionnaire has about 40 questions so this lives in a questionnaires table with a user_id field to relate to the users table.
Just one example :-)
1 like
Level 3
Yes, i see, your totally right, in my case makes quite sense seprating the tables users, since there is quite information that they dont shared, and would be much easyer to work it. For example when i create the user by my example create a record in user and employer/jobseeker. But is like you say regarding the shared information, thanks for your feedback @Screenbeetle
Please or to participate in this conversation.