我们应该使用 DAX 还是 M 构建桥接表？
图片盗自here
使用 DAX 似乎很诱人。使用 DAX，代码简洁明了：
IDList = DISTINCT(
UNION(
DISTINCT(Table1[ID])
,DISTINCT(Table2[ID])
))
此外，DAX 表不需要加载为 M 表。但是我想知道 DAX 相对于 M 的优势是否不是虚幻的？ M 似乎只加载一次，而 DAX 似乎是在运行中计算的，可能在任何时候，一遍又一遍？
【问题讨论】：
标签： powerbi dax powerquery m bridge
如果它从中提取数据的任何表以任何方式刷新或更新，则会重新计算 DAX 计算表。 （来自https://docs.microsoft.com/en-us/power-bi/desktop-calculated-tables）
它们不会“即时”重新计算，也不会“一遍又一遍”地重新计算。 Power BI 数据模型的刷新周期在使用 DAX 计算表或 M 查询表之间没有区别。但是，您可能会发现 DAX 计算表的刷新速度比 M 快，具体取决于表的复杂性...
【讨论】：
考虑 M 个表、M 个条件列、M 个自定义列、DAX 表、DAX 计算列和 DAX 度量。只有 DAX 度量 是动态创建的，而不是数据模型的一部分。
所以对于一个简单的桥接表，DAX 表和 M 表彼此之间没有真正的优势。
两个表都允许一个创建关系。现在，当我说简单的 Bridge Table 时，它是由 2 个或 3 个表创建并使用同一列与两个或多个表建立关系的东西。
但是当需求变得复杂和敏捷（随着时间的推移而增长）时，维护和开发工作也会增加，如果它是由 DAX 创建的。 （我个人的意见，我想大多数人的个人意见也是如此。）
如果它是由 M 创建的，那么添加新列或基于逻辑的过滤器或替换现有值会更容易。
回到拇指规则：- 如果它是由 DAX 创建的，则不能在其之上使用 M 进行更改。因此，如果桥表是由 DAX 创建的，那么它将不会出现在查询编辑器中，并且限制了 GUI 的优势，无法对数据进行任何所需的简单转换。
对于一个简单的桥接表：- DAX。
但对于复杂且不断变化的需求：- M.
【讨论】：