You can also construct them the way PowerBI does, using VAR:
VAR __MyFilterTable = FILTER( T, T[col] = "red" )
RETURN
SUMMARIZECOLUMNS (
T[col],
__MyFilterTable
)
Which is more efficient will depend on the complexity your filtering, so there is no "one size fits all" rule necessarily. For a simple table level filter, just FILTER will suffice. I caution you that Line 1, where you're filtering the entire table T, is a bad idea. It's much more performant to only filter a single column. When you filter the entire table, DAX materializes the entire table in memory, while the following just materializes the one value of T[col]:
VAR __MyFilterTable = FILTER( ALL(T[col]), T[col] = "red" ) // This is better.
RETURN
SUMMARIZECOLUMNS (
T[col],
__MyFilterTable
)
You can do even better than that, conceptually. You can basically tell DAX, "I know this is a value, so don't even look in the table for it. Just make me a table and treat it as though I filtered it. Like this:
VAR __MyFilterTable = TREATAS ({"red"}, T[col] )
RETURN
SUMMARIZECOLUMNS (
T[col],
__MyFilterTable
)
Again, this is the pattern that PowerBI uses when performing its filters.
BTW, Creating the filter tables a the top vs. creating them inline with SUMMARIZECOLUMNS() won't make any difference for speed. Avoid using CALCULATETABLE() as you've done here generally.
You can also do this as well, though you aren't likely to see a speed increase generally:
CALCULATETABLE(
SUMMARIZECOLUMNS (
T[col]
),
KEEPFILTERS(T[col] = "red")
)
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…