Forum Discussion
Joins in SQL vs using relationships performance
Anonymous ,
The answer depends on how you want to shap your data model. Best Practice is a Fact Table (contains the items that you want to summate, count, etc), and a few Dimension tables (ones that will help you filter the fact table).
If your PBI data model requires the two SQL tables to be in one table, then join on loading via the SQL script. Or if you access to the SQL DB, create a View that joins them, then you can just load the view into PBI.
Also, as v-diye-msft said, the Relationships in PBI act in certain ways. This may not be in the way you need for your model, as the relationships are filter relationships not joins.
hope that helps.
Anonymous ,
The answer depends on how you want to shap your data model. Best Practice is a Fact Table (contains the items that you want to summate, count, etc), and a few Dimension tables (ones that will help you filter the fact table).
If your PBI data model requires the two SQL tables to be in one table, then join on loading via the SQL script. Or if you access to the SQL DB, create a View that joins them, then you can just load the view into PBI.
Also, as v-diye-msft said, the Relationships in PBI act in certain ways. This may not be in the way you need for your model, as the relationships are filter relationships not joins.
hope that helps.
Thank you both so much for your answers. I thought I understood what relationships are for - linking tables. What I completely missed was that relationships indeed filter results, not join them.
So the two methods are somewhat the same, yet the results can be very different.