Lot of different ways you can do this. You could use RANKX, calculated column using COUNTROWS/ EARLIER, etc. I’m not sure that there is a general best practice here – would seem to depend on what you’re indexing.
No worries. I did mine is a measure, so when you’re doing a calculated column you don’t need SELECTEDVALUE, since the calculated column by nature provides row context. This is also why it’s helpful to see the PBIX file with the data model. Here’s one way to do the index based on your Dates table and data model:
DAX Index =
LOOKUPVALUE(
Dates[Month Of Year],
Dates[Short Month],
'Short Months'[Short Month]
)
However, given that it looks like you’re going to be using this short month table to filter other tables, I would recommend creating it in Power Query, rather than DAX to avoid potential circular reference problems down the road.
That was my next question as when you create tables in the table view via dax u don’t see them in the power query whats the difference? Is better to do them via dax does this save on file size ? If not I’d always prefer to create my tables in power query i think ? What’s your preference?
That’s correct – tables created via DAX expressions are not accessible via Power Query.
I wouldn’t worry about file size in this case. The VertiPaq compression engine in Power BI is extremely efficient, and so any table that you could create via DAX that would run at an acceptable performance level is unlikely to have a large impact on file size. This is a gross oversimplification, but not a bad general rule - “if you can do it in Power Query you probably should…”
Doing more “upstream” in Power Query will improve performance and also simplify your DAX, making it easier both for you and for anyone reviewing your model/report.
@AntrikshSharma puts it this way, which I like - SQL > Power Query > DAX.