Datamodel: Best practice / Optimize performance on large tables

v-lili6-msft PBIX sample is avaliable here, with dataset limited to a single "customer" - PBIX Sample

My described table A would be "fAccess_Granting_From_To_Dates' and 'fProducts Sold' is table B.

Table 'fAccess_Granting_Days' is the same information, but from and to dates expanded to individual dates, as described above.

Note:

I'm aware that I can summarize table 'fAccess_Granting_Days' by removing the "Access_Granting_Product" column. But I'm later expecting to be able to answer which products customers had access through, so I'm keeping it for now.

As you can see from the table row counts, expanding the dates increases row count from 19 to 1.146 - the cardinality will however not explode dramatically.

The following measure is not finished, but somewhat describes what I want to achieve:

Customers without re-purchase, but Access now = 
VAR Access_Now = CALCULATE( COUNTROWS( fAccess_Granting_Days ) )
VAR Products_Sold_This_Month = CALCULATE( COUNTROWS( 'fProducts Sold' ) )
VAR Products_Sold_Last_Month = CALCULATE( COUNTROWS( 'fProducts Sold' ) ; PREVIOUSMONTH( dDates[Date] ) )
RETURN
CALCULATE( DISTINCTCOUNT( dCustomer[CustomerID] );
    //Count Distinct Customers
    FILTER( dCustomer ;
    //Filter Customer Table to find customers with no sales this month, but sales last month and have access now
        Products_Sold_This_Month = 0 &&    
        Products_Sold_Last_Month > 0 &&
        Access_Now > 0 )
)

I'm aware that for DAX / end-user performance, table 'fAccess_Granting_Days'  is preferable to "fAccess_Granting_From_To_Dates' is it should return much faster query times, as a measure on "fAccess_Granting_From_To_Dates' would have to itterate over the entire table to check for the correct dates.

I'm however afraid that 'fAccess_Granting_Days' will grow far to big.

So what is the suggestion for best practice in such cases?