MDX如何求解：统计某段时间的价格带偏好为XX值的会员，如2015.10.1-2015.10.7，价格带偏好是300-400的会员
0
有order这个cube，其中有日期维度，会员维度，价格带维度
价格带偏好的逻辑是购买次数最多的价格带。比如A会员 100-200的订单1单，200-300的2单，则价格带偏好是200-300
B会员 200-300的2单，300-400的4单，则价格带偏好是300-400
现在需求是：
统计某段时间的价格带偏好为XX值的会员，如2015.10.1--2015.10.7，价格带偏好是300-400的会员
没有找到相关结果
重要提示：提问者不能发表回复，可以通过评论与回答者沟通，沟通后可以通过编辑功能完善问题描述，以便后续其他人能够更容易理解问题.
5 个回复
xpivot - SSAS & Excel &Cube架构师、产品经理 课程地址：http://www.hellobi.com/course/34 2015-08-10 回答
赞同来自: 梁勇 、choc 、天涯浪子
首先，为什么一定要使用MDX？也许是信了坊间流传的Cube的查询性能一定是优越于DB的，因为Cube有预计算，有聚合处理，那么一定会让你失望的是，这个想法并不是无往不利，Cube和DB的查询优化器工作原理有很大差异，就拿你这个案例来说，用MDX Filter来实现查询，原理类似于MSSQL的Cross Apply，是要遍历循环每个会员，对每个会员进行事实度量值的聚合汇总，然后再对所有会员汇总后的度量值进行分组，也许你会说DB QO也是如此啊，SQL子查询方式来实现看执行计划可能也是个Nest Loop循环，非要这么说的话，Cross Apply其实也算是个Nest Loop，那为什么还会和子查询的写法有很大的性能差距呢，举个例子来说比较容易理解些，就像你去取款机取一万块钱，ATM点钞的过程就是个Nest Loop循环，一把取出来一万元是在内部循环了一百次点钞的过程，而分一百次每次一百元取款，同样的一百次点钞循环，取款效率是不是低了很多。所以如果仅仅是因为性能的原因要全盘MDX化，建议重新审视下数据库是否已经优化到没有任何提升空间了，如果SQL能够高效简便的解决问题，实在没有太多基于性能上的理由选择MDX，也有可能是你的数据源只有Cube，所以没得选择只能MDX，那么我想说这个架构可能是非常危险的，MDX的可维护性远不如SQL，正常的人事变迁都有可能使整个项目陷入无人支持维护的境地。
其次，选择MDX的一个让我无法抗拒的理由是它的多维聚合分析能力，这个是SQL不容易实现的，这时候一定也会有SQL万能论者难以苟同，我得强调下，这里的不容易实现特指的是自助式BI平台，如果你有对比过ROLAP和MOLAP实现的自助式BI的实现原理，是能够理解MOLAP在这个方向上得天独厚的优势
最后，只剩一句话了：让上帝的归上帝，凯撒的归凯撒吧，SQL和MDX结合起来用可能才是你想要的理想答案
天桥下的郑成功 - Hadoop大数据开发工程师、数仓架构师、熟悉数据仓库设计、Hadoop、Spark、HBase、Hive、SSIS等开发 2015-08-04 回答
赞同来自:
你的价格带维度是不是如我下面所说设计的？
订单事实表:
客户ID 价格带ID 物品ID 数量
1 1 1 100
价格带维度表:
价格维度带ID 价格带包含信息 最低价格带 最高价格带
1 包含100-200 100 200
lqishi - IT狗 2015-08-04 回答
赞同来自:
天桥下的郑成功 - Hadoop大数据开发工程师、数仓架构师、熟悉数据仓库设计、Hadoop、Spark、HBase、Hive、SSIS等开发 2015-08-04 回答
赞同来自:
怎么这个 维度表 还有 客户ID的？
天桥下的郑成功 - Hadoop大数据开发工程师、数仓架构师、熟悉数据仓库设计、Hadoop、Spark、HBase、Hive、SSIS等开发 2015-08-10 回答
赞同来自:
带带wo