Forum Discussion

Koritala's avatar
Koritala
Post Patron
5 months ago
Solved

Duplicate Table best approach

Hi All,

I have a doubt on creation of duplicate table in power bi desktop.

I need to create a duplicate table for dim_date to make a new relationship.

this we can do in 2 ways like by creating the duplicate in query editor or by using DAX we can create the same ussing duplicate date table= 'dim_date'

My question is that which optoin above is best for the performance and model size point of you.

Appriciate if you anyone can confirm.

Thanks,,

Sri

 

  • Hi Koritala,

     

    You should create the table in Query editor as it's best for report performance.

     

    Table is loaded during report refresh

    it is recommeded by Microsoft modeling best practices

    Cleaner data lineage

    Easier to maintain transformations

     

    🌟 I hope this solution helps you unlock your Power BI potential! If you found it helpful, click 'Mark as Solution' to guide others toward the answers they need.
    πŸ’‘ Love the effort? Drop the kudos! Your appreciation fuels community spirit and innovation.
    πŸŽ– As a proud SuperUser and Microsoft Partner, we’re here to empower your data journey and the Power BI Community at large.
    πŸ”— Curious to explore more? [Discover here].
    Let’s keep building smarter solutions together!

  •   

    Reference your dim_date query in Power Query (right-click β†’ Reference), not Duplicate or DAX table.

     

    Why:

    Duplicate re-queries source (doubles refresh time)

    DAX calculated table = uncompressed, 5-10x larger model

    Reference = zero storage hit, instant refresh, single source of truth

     

    If this answer helped, please click πŸ‘ or Accept as Solution.
    -Kedar
    LinkedIn: https://www.linkedin.com/in/kedar-pande

  • If you right-click dim_date β†’ Reference, Power Query creates a new query that points to the same upstream steps. 

    • Does not re-query the source (unless transformations diverge later)

    • Keeps one source of truth

    • Very clean lineage

    • Transformations can still be adjusted independently later

    But if your only goal is to use multiple dates from the same fact table, another common pattern is:

    • keep one main Date table
    • create multiple relationships
    • use USERELATIONSHIP() in measures when needed

    That avoids adding extra date tables unless you specifically need separate slicers/filter behavior.

3 Replies

  • Hi Koritala,

     

    You should create the table in Query editor as it's best for report performance.

     

    Table is loaded during report refresh

    it is recommeded by Microsoft modeling best practices

    Cleaner data lineage

    Easier to maintain transformations

     

    🌟 I hope this solution helps you unlock your Power BI potential! If you found it helpful, click 'Mark as Solution' to guide others toward the answers they need.
    πŸ’‘ Love the effort? Drop the kudos! Your appreciation fuels community spirit and innovation.
    πŸŽ– As a proud SuperUser and Microsoft Partner, we’re here to empower your data journey and the Power BI Community at large.
    πŸ”— Curious to explore more? [Discover here].
    Let’s keep building smarter solutions together!

  •   

    Reference your dim_date query in Power Query (right-click β†’ Reference), not Duplicate or DAX table.

     

    Why:

    Duplicate re-queries source (doubles refresh time)

    DAX calculated table = uncompressed, 5-10x larger model

    Reference = zero storage hit, instant refresh, single source of truth

     

    If this answer helped, please click πŸ‘ or Accept as Solution.
    -Kedar
    LinkedIn: https://www.linkedin.com/in/kedar-pande

  • If you right-click dim_date β†’ Reference, Power Query creates a new query that points to the same upstream steps. 

    • Does not re-query the source (unless transformations diverge later)

    • Keeps one source of truth

    • Very clean lineage

    • Transformations can still be adjusted independently later

    But if your only goal is to use multiple dates from the same fact table, another common pattern is:

    • keep one main Date table
    • create multiple relationships
    • use USERELATIONSHIP() in measures when needed

    That avoids adding extra date tables unless you specifically need separate slicers/filter behavior.