Forum Discussion
table qualified columns
Thanks for the feedback on the book. I will pass it on.
Regarding the DAX, I am pretty sure I am not confused, but happy to be corrected if I am wrong.
Ffitzpatrick47 wrote:the general rule should just be qualify all your columns, because qualifying only dimension columns clearly doesnt' work as a rule.
This is the rule (best practice) = always qualify all columns. There is no rule that I am aware of that says "only qualify dimension columns". Where did you get this rule from?
Ffitzpatrick47 wrote:Second, if you read page 56 of the collie book, it says right there: to reference a measure we omit the table name
That is exactly what I said in my blog article linked above.
Ffitzpatrick47 wrote:
if you watch the Ferrari video https://www.sqlbi.com/tv/advanced-dax/, he explicitly says he refuses to touch a model where the measure convention with the table names are not followed.
I totally agree and this is entirely consistent with what I said earlier and in my blog post and in my book.
I think you are confusing 2 concepts (maybe I am wrong, not sure, but this is how I am interpreting what you are saying).
Concept 1. Naming conventions.
Columns should always be named TableName[Column Name] Always, always, always - no exceptions.
Measures should always be named [Measure Name] excluding the table name, always, always always, - no exceptions.
Concept 2. Refering to Column Names inside a Measure Formula.
This is a totally different thing. If you are refering to a column name INSIDE a measure formula, you should always qualify the column name as TableName[Column Name].
Have I misunderstood what you are saying?
Your formula doesn't work because you need to use the FILTER fuction as I showed above.
Yes I got the formula to work, it was an early in the process when I took the picture, I just wanted to show the intellisense.
This is where we differ. The definition of measure is one of two things
1. The conventional definition:
so, if you did sum(amt) in a fact table that has amt as a column, the measure is the column amt, and it can be aggregated with summed average etc.
2. Probably your definition, not sure if it's everyone elses, but if it is, suddently everything makes sense since the rest of DAX doesn't follow typical programming convention.
Measures are the executed aggregate function such as sum(amt) returning an aggregate value?
The whole dax language does not use conventional terminology so it may be that "measures" is used differenlty here than in the rest of the world. Microsoft did this to ie6 so if everyone drank the koolaid, I guess 2 may be right. If DAX spelled out its data types in their documentation like every other language in the world does in their documentation, this wouldn't be such a hard medium to communicate with others. I don't mean like primitives. I mean like these "measures". For example the documentation for calculate is
CALCULATE(<expression>,<filter1>,<filter2>…)
But that's clearly not the case because in every other language, https://en.wikipedia.org/wiki/Expression_%28computer_science%29
x=5 is an expression. What really belongs in <expression> is what the #2 version of the definition for the word "measure" actually means, if indeed I'm interpretting your definition of measure correctly. This is like learning french, except the words are exactly the same as english. It's just a different meaning, like a Rene Magritte fan trying to prove a point in computer languages.