主要是因为今天做表时，用treatas时，将前后参数的的位置写反了，导致结果对不上；
后来用userelationship结果就对上了
| ITEM | CONTENT |
|---|---|
| 同 | 都可以构建关系 |
| 异 |
treatas可以在没有关系的情况下使用，更灵活，可以自己构建； Userelationship仅在有未激活关系的情况下使用 |
--treatas更灵活，可以构建不存在的列
MEASURE = CALCULATE([度量值], treatas({"Blue","Red"}, 'table[column]))
--定义任意关系的筛选器
--检索在法国销售的蓝色产品和在爱尔兰销售的绿色产品的数量
EVALUATE
SUMMARIZECOLUMNS (
'Date'[Calendar Year],
"Quantity", CALCULATE (
SUM ( Sales[Quantity] ),
TREATAS (
{ ( "Blue", "France" ), ( "Green", "Ireland" ) },
'Product'[Color],
Customer[Country]
)
)
TREATAS
treatas前后字段很重要，
TREATAS(table_expression, <column>[, <column>[, <column>[,…]]]} )
| Term | Definition |
|---|---|
| table_expression | An expression that results in a table. |
| column | One or more existing columns. It cannot be an expression. |
该表达式返回一个表，然后在calculate中用返回的表进行筛选
使用时，可以理解为维度表在前，明细表在后
Userelationship
image.png
用在calculate中，临时激活虚线的关系
常使用在有两个字段需要与维度表关联时， 比如截图时下单日期和发货日期需要与日期表相连。
使用时，列的顺序无所谓；通常的做法是先使用关系的多面（Sales），然后使用单面（Date），不过不影响结果。
使用建议
性能上：建模视图构建关系>userelationship>treatas>intersect>filter
但是treatas可以做非侵入式设计，减少对模型主要关系的干扰。
所以，需要在设计与性能间平衡。
Detail please refer to
https://www.sqlbi.com/articles/propagate-filters-using-treatas-in-dax/
