Forum Discussion
Super UserHow to create hierarchy not in fct table or based on integer key columns?
jaryszek ,
Thank you for sharing your blog post.
- The RELATED () function pulls data from a related table into the current one, typically used in calculated columns.
- This operation is evaluated during data refresh, not during report interaction. So, it affects model processing time, not query performance.
We appreciate your engagement and thank you for being an active part of the community.
Best Regards,
Lakshmi.
Community SupportHi jaryszek ,
Your right to be concerned about performance when dealing with long string fields in shared or bridge tables. If we combine Dim_Subscriptions and Dim_ResourceGroups into a single dimension or use a bridge table, and those tables include verbose string columns like full subscription names or resource group paths, it can definitely impact performance especially in large models. Long strings increase memory usage, slow down joins and filtering, and reduce compression efficiency in VertiPaq. To mitigate this, we typically rely on surrogate keys for relationships and keep long strings only for display purposes. Another option is to push hierarchy logic to the reporting layer using DAX or calculated columns, which avoids bloating the model. So yes, if not carefully designed, bridge or shared dimension tables with long strings can degrade performance, but with proper modelling techniques, you can still preserve hierarchy logic without sacrificing efficiency.
Best Regards,
Lakshmi.
Super Userthank you,
"o mitigate this, we typically rely on surrogate keys for relationships and keep long strings only for display purposes."
ok so if i will put bridge table with integer keys connected to Dim_tables, it should work?
But How to build hierarchy from integers, not strings?
Best,
Jacek