Forum Discussion
Best Practices with very large SQL Server Views
Normalizing is an option worth trying. Not only because it reduces the total amount of data, but also because the tabular engine likes it more: Simply spoken: Tabular has no problem with long (narrow) table, but will tend to slow down with (even short) wide tables.
So everything that will reduce the number of columns (and their cardinality) will help you here.
Well, you could post the SQL here and see if it can be optimized. Otherwise, the general recommendation is that you create a cube and hook Power BI to that.
Yes, that's a possibility...but I'd like to avoid that, since the data is quite dirty and I wanted to move the calculation work to Power BI.
If I created a cube on my data and import the cube to Power BI, would the cube weight much less than the import of the data?
That may partially solve my problems: I could create the cubes from the tables created from the views. In this way, I may import the cubes to Power BI, but I'd have a lot of space occupied by such tables in SQL Server Database :( .
Normalizing is an option worth trying. Not only because it reduces the total amount of data, but also because the tabular engine likes it more: Simply spoken: Tabular has no problem with long (narrow) table, but will tend to slow down with (even short) wide tables.
So everything that will reduce the number of columns (and their cardinality) will help you here.
I guess I'll try normalizing the data...
20+ columns for a fact table are way too much, and I guess it's easier than creating a cube and use it by direct query.
Thanks.