But this might pose a problem with incremental refresh? Might have different combinations in different days. Might have to incrementally build junk dimension in ETL.
Any Vertipaq performance benefits in combining these small dimensions into a junk? I would imagine it improves multi dimension filters (it only has to scan one dim table), but suffers from single dimension filters (it has to scan a larger dimension than it would have). I would think fact compression should remain the same. Overall, maybe ever so slightly better performance?
I had to change playback speed to 0.5 in order to follow this video, and with several pauses to read the parts with SQL code. Seemed like Patrick was in a hurry.😅
Really good video, I can definitely see me trying to use a Junk Dimension in the future to simplify my Star Schemas. I also watched your Saturday Session at SQLBits 2023 and it was really good, and downloaded the slides. The slides show Serverless SQL optimisation and partition elimination for Delta, but there are no demos, so future videos on those would be great.
Interesting video. Your junk dim doesn't look like most junk dims I've found in corp data warehouses. What I typically see is that the primary key for the fact is also the key for the junk dim, which gives no benefit of grouping to the junk dim in Power BI. It may be that with 20+ columns in the junk tables, the benefits are not as significant as if there were only 2 or 3? With your approach to the junk dim, the junk key is different and the junk table has less rows than the fact.
Hi I have doubt ,after dashboard development ,i have patient registration date and registration expired date i have taken registration date for patient admission and discharge for registration expired date how can I take the date filter to get the correct values for whole dashboard
Junk dimensions are great for performance and readability, but maintaining them can be a pain. If you want to add a new column you have to remap all the fact rows
Nice one. I was used to using the cross join method! I like the alternative a lot. Don't see junk dimensions a lot these days
Good overview, would have loved to see at the end what the junk dimension table looks like in Power BI and how the performance improved
But this might pose a problem with incremental refresh? Might have different combinations in different days. Might have to incrementally build junk dimension in ETL.
Was just reading about them in Kimball. Need to use them sometime.
Terrific Patrick ! I learnt it lot from you guys .
Would definitely eager to see how this can be done in power bi directly...
Any Vertipaq performance benefits in combining these small dimensions into a junk?
I would imagine it improves multi dimension filters (it only has to scan one dim table), but suffers from single dimension filters (it has to scan a larger dimension than it would have). I would think fact compression should remain the same.
Overall, maybe ever so slightly better performance?
yup no comprhenisive discussion on this
I didn’t get that! It went super fast. I have to re watch a few times!
Me too!
I had to change playback speed to 0.5 in order to follow this video, and with several pauses to read the parts with SQL code.
Seemed like Patrick was in a hurry.😅
Really good video, I can definitely see me trying to use a Junk Dimension in the future to simplify my Star Schemas. I also watched your Saturday Session at SQLBits 2023 and it was really good, and downloaded the slides. The slides show Serverless SQL optimisation and partition elimination for Delta, but there are no demos, so future videos on those would be great.
in fact is will bring wrong calculations at same point due to auto-exist and you will have no idea why.
Interesting video. Your junk dim doesn't look like most junk dims I've found in corp data warehouses. What I typically see is that the primary key for the fact is also the key for the junk dim, which gives no benefit of grouping to the junk dim in Power BI. It may be that with 20+ columns in the junk tables, the benefits are not as significant as if there were only 2 or 3? With your approach to the junk dim, the junk key is different and the junk table has less rows than the fact.
Just started listening to your P3 Raw Data podcast interview. Small world.
Hi I have doubt ,after dashboard development ,i have patient registration date and registration expired date i have taken registration date for patient admission and discharge for registration expired date how can I take the date filter to get the correct values for whole dashboard
Junk dimensions... Interesting.... Thanks🧐
Junk dimensions are great for performance and readability, but maintaining them can be a pain. If you want to add a new column you have to remap all the fact rows
I would like to see how this works with Power BI.
Please.
in fact is will bring wrong calculations at same point due to auto-exist and you will have no idea why.
I would like to see how this plays out in building a Power BI data model.
in fact is will bring wrong calculations at same point due to auto-exist and you will have no idea why.
way to fast