Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.
Hi guys, just wondering if its better to do all the lookups in SQL view or import the related tables and do the relationships in the model?
For instance, I have a Journal table with about 2 million rows. each record has a reference to an emplyee table and returns the employee name.
I can write a view that does the lookup in SQl and pull it into my model
or pull both tables into the model and do the relationship and lookup in the model.
How do these 2 methods affect performance?
which way is more condusive for direct query or import mode?
thanks guys
i
Solved! Go to Solution.
SQL is no subsitution for DAX, that's for sure; but push as much work as possible to database for preparing fundamental dataset. That's my advice.
Thanks to the great efforts by MS engineers to simplify syntax of DAX! Most beginners are SUCCESSFULLY MISLED to think that they could easily master DAX; but it turns out that the intricacy of the most frequently used RANKX() is still way beyond their comprehension! |
DAX is simple, but NOT EASY! |
There is no direct comparative relationship between the two methods.
Consider the optimization possibilities for a DirectQuery model. As the model issues query requests to the underlying datasource, datasource optimization is critical to delivering responsive model queries.
What you can do at the datasource layer:
Because of the case-by-case analysis, you can use SQL Profiler to perform performance analysis on data models built using both methods.
If you still have some question, please don't hesitate to let me known.
Best Regards,
Link
Is that the answer you're looking for? If this post helps, then please consider Accept it as the solution. Really appreciate!
There is no direct comparative relationship between the two methods.
Consider the optimization possibilities for a DirectQuery model. As the model issues query requests to the underlying datasource, datasource optimization is critical to delivering responsive model queries.
What you can do at the datasource layer:
Because of the case-by-case analysis, you can use SQL Profiler to perform performance analysis on data models built using both methods.
If you still have some question, please don't hesitate to let me known.
Best Regards,
Link
Is that the answer you're looking for? If this post helps, then please consider Accept it as the solution. Really appreciate!
SQL is no subsitution for DAX, that's for sure; but push as much work as possible to database for preparing fundamental dataset. That's my advice.
Thanks to the great efforts by MS engineers to simplify syntax of DAX! Most beginners are SUCCESSFULLY MISLED to think that they could easily master DAX; but it turns out that the intricacy of the most frequently used RANKX() is still way beyond their comprehension! |
DAX is simple, but NOT EASY! |
Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City
Check out the April 2024 Power BI update to learn about new features.
User | Count |
---|---|
114 | |
101 | |
78 | |
75 | |
49 |
User | Count |
---|---|
145 | |
108 | |
107 | |
89 | |
61 |