Level 122
if you are sure customers even need to log in?
Splitting to two tables would be my absolute last resort- everything else you mentioned is just roles of the authenticated user
1 like
Sep 14, 2023
2
Level 5
Do you split the user table for a monolith system that serve both internal and public facing apps?
Suppose you build a shop. You will need an internal system to manage employee, products, etc. And a public facing app for customer, they can search, sort, purchase, manage favorite items, etc.
In such a system, the "user" of both system is very different. They most likely also have hierarchy of their own.
user of the internal system is Employee, who could be Manager, Worker, Receptionist, Customer Support, etc. While user of public facing app may be bronze, silver, gold member, etc.
For these kind of system, do you split your users table to something like employees and customers, or do you manage it in the application level?
Level 75
It depends what the specification calls for. A huge insurance carrier (as example) will normally have patient and Doctor's and Hospitals separate. For example Humana has patient portal, Doctors portal, Government entity portal.
So if a doctor is also a patient using the system it would be a separate login.
However most average apps just one user table is all that's needed. Keep it simple but implement good security. And take the several months to learn this stuff, don't pull shortcuts when it comes to security.
Do you split the user table for a monolith system that serve both internal and public facing apps?
The State of Texas DADS (Department of Aging and Disability Services) had separate main applications. What the public logged into verses what was on the servers used at DADS was completely different.
Just my opinion, but I don't see the average Laravel user writing huge enterprise programs like either I described, so one user table is probably all you will ever need.
1 like
Please or to participate in this conversation.