We want to avoid ‘view bloat’, creating a new User view/join for every single one of these specific use cases. However, the data needs to remain readable for Blobby and stay performant as we scale.
What is the recommended approach in Omni for handling these role-playing dimensions? Should we be leveraging specific join logic, Aliased Views, or is there a way to dynamically map these attributes without duplicating the User metadata dozens of times?
What columns do you want to bring in from the users table for each of these? If it’s just a couple of fields vs multiple dependent views (ie user_attributes_1, user_attributes_2, etc).
A simple join-alias template may be a simple way to handle, but helps to have a bit more tangibility on what you need with each.
It’s different for every use case but most of the times we have seen same 3,4 dimensions such the user_name, user_role, user_market, user_creation_date etc.
So you’re suggestion of join-alias template would still create multiple views right?
Would still be a view you are joining in, but I think a template could simplify the whole thing. Need to test but if we write a template with the join, view + fields, then you’d be able to extend that template with a line just to direct to the desired key.
So this is the screenshot of one of our existing Looker Explores.
User view: is the master user table
Task Creators and Task Completors views are derived from the User view but joined user_id on base view’s creator_id and completor_id fields to grab related id’s user information.
In a perfect world, we want to get away from creating multiple versions of the user views.
