Hi,
I have a user table with all the user names, role, e-mail and other columns. There are multiple rows and users keep getting added to this table.
I am creating another new table - ‘user wise analytics’ where i want to get the names of all users from the user table. Basically this new table’s column of users is a replica of the user table user name column and dynamically reflects changes in names as they are changed in the main user table.
All my current approaches only are able to change the first row or they bring all names in a single cell, i’m not able to bring all rows for user names column from the user table to the new table.
How would you match a row in your second table to a row in your first table?
You need something that is unique to each user - either a UserID (RowID) or email address in each row in your second table. Then you can use that to create a relation back to the first table, and then a Lookup via the relation to fetch the name.
That was the issue. The second table has nothing in common with the first table except for the names, which is why i was stuck. Maybe i should just have the second table’s user name column get auto-populate using a workflow which is triggered everytime a new user is added, that way the name column shall always be in sync in both tables.
As a general rule, it’s better not to duplicate data across tables. So a better approach is to add a UserID or email address. Then if a user ever edits their name, it only has to be changed in one place.
If you are created user-based analytics, is there a reason why you are writing the analytics to a new table instead of the users table?
I don’t know if it’s the right way to do it, but when I’ve had to build analytics for certain parts of an app by hand (analytics that PostHog won’t handle), then I store these in the users table.
I try to keep the users table ‘sacred’ because it is the point of access control to the app so i don’t like adding anything to that table unless there isn’t an option.
Interesting take on the users table, but the user table is made to be highly customizable as well, I think your missing out on ALOT if you don’t curate the user table to feed your app I have 100s of columns in some of my apps users tables. Lots of relations and queries to give user based row owner data, and user level app customization
I used to think the same and my view of the users table has evolved. I now make use of the users table more liberally. I will now store data that pertains to users, such as user-based analytics data, in that table. Screens will usually be sourced to one of two tables: the users table if the screen is user-specific, a table called “configuration” if the screen is global.