Hi all,
Currently we have a User table, then in the User table we have a User Type and a Joined Table for the type of user they are. I’ve set this up this way as Bubble forces you to use one user table, but with so much flexibility in Wappler, would anyone recommend a different ‘user’ table for each user type, or still keep all user credentials on a basic user table and then hold the unique data of each type on a separate table?
When you talk about different user types are you talking about users with different levels of access/permissions for your app?
I tend to separate strict user data from app/account/profile data.
So one table that holds id, email/username, password, tokens, account booleans, etc.
And secondary user tables that hold user data specific to the app that may or may not include PII.
Completely different user types, e.g. a marketplace might have a buyer / seller. Uber will have drivers / riders.
In Ubers example, would they use one master table that just holds core user information like email, username, password, and then just link to a separate table for ‘drivers’ information and ‘riders’ information?
Thanks @JonL - this is how I have it currently setup, it seems like this is the right approach - spent time reviewing articles online and most tend to just follow this.
The complications come in when there are drivers who are also riders or buyers who are also sellers. I find it easier to have one log in table to handle the user’s credentials and then separate profiles that show what access they have.
The approach that has worked best for me is to have activation record(s) for each user. So a user can have their login but they have activations associated to it. Theoretically you could then have separate activations for the same user but for their different roles.
e.g. a Uber user could have a driver activation that gives the permissions to a driver part of the platform/site and a separate rider activation to manage privileges to that part of the platform/site
This method allows users to log in to manage privacy preferences etc. but only has access to relevant sections when the activation is confirmed by the organisation (either programatically or manually)
Thank you for the detailed reply. Can you elaborate on your activation record(s), what these are specifically and how you handle it in the DB/what it looks like?
I have a user account table that holds the basic user details (enough to log in).
There is a separate table (or tables if you want separate activations for buyers/sellers etc. - I have a business admin site that has separate activation tables for staff, board members, investors, management). This table has a foreign key ref to the member id as well as a status (starts as ‘pending’, ‘active’ once confirmed and ‘blocked’ if the org removes access). It also has a column for the profile id assigned to that activation (a FK ref to a profiles table - I usually have separate profiles tables for the roles)
I don’t know if it is relevant but, in my case I also have users who log in to multiple organisations so they can have an activation for multiple roles with multiple organisations.
e.g. User A is a investor and board member of Company 1 as well as a board member of Company 2 as well as a member of staff at Company 3 etc…
This is excellent, thank you for the detailed explanation.