Let's say you have employees, vendors and clients. Would you group them under one user table with a type column or make three unrelated tables? They can have many of the informational columns (like name, email, phone, etc) the same but not "related" in the sense that you're less likely to query for all addresses across all types of users
#One `users` table vs multiple `specific_type` tables
main finch
vital nova
Conceptually you might like to think about this like users and roles (with separate Role model) that way everywhere in the app you can use the user role (vendor/employee/client)
PS not sure if it's in your scope but that would also allow scope for a user to have more than one role...
main finch
PS not sure if it's in your scope but that would also allow scope for a user to ...
For the current iteration, they can't. But in the future they may but they will have different login route
I was thinking about if the user table grows "too big" (slow query?) but now it sounds like overoptimisation
vital nova
I wouldn't worry about that unless it becomes a problem - if it does then you're doing incredibly well 🙂
tacit axle
I was thinking about if the user table grows "too big" (slow query?) but now it ...
A table can hold billions of rows without a problem