Linux的创始人Torvalds在一次演讲中有一段涉及“什么才是优秀程序员”的话:“烂程序员关心的是代码。好程序员关心的是数据结构和它们之间的关系。”
在bw的世界里,也是如此。若只是关心是否能实现,不在乎模型的复用性,维护性,可拓展性。做出来的东西简直是惨不忍睹。这段时间,看了自己在10多年前做的模型(那时候我刚刚学习bw),那是做为菜鸟的我关心的就是把逻辑实现做出报表。模型设计上,可以说很是欠缺,几乎没有。在后来不断学习中(遇到了很多牛人),我也开始慢慢在学着多思考模型如何设计,为什么这样做比那样做好,强,方便?好在哪里,强在哪里,方便在哪里?后来再做项目和模型的时候,我都会反复思考推敲,这样做出来的模型更稳定,更强壮,更容易维护。对我自己来说,也更有成就感,更有意思,更开心。(组合这些技能,就像小朋友玩乐高玩具一样,只要充分发挥个人想象,就能得到各种各样的功能。)
有了hana,现在的bw可以设计的更简单,更强壮,更容易维护。
1 ODP/CDS 做为源系统数据源的技术基础
2 BW 负责基础层和整合层(TR注释须详细)
3 hana view 负责数据和报表输出 (script注释须详细)
cube/psa/mp这些对象都已经在慢慢退出了历史。不过未来是bw cloud…
-----------------------------2022/09/16 更新-------------------------------------
以前服务器硬件有限,但是存储相对便宜,所以大体的设计思路基本都是空间换时间,简而言之就是将需要的数据或者是展现的数据合并在一起,最后去掉明细维度(也是为了保证速度)。
现在到了hana或者类内存的数据库,个人觉得这种空间换时间,已经不合适,而且非常不合适了。本来内存相对来说比较宝贵,不需要那么多冗余数据,明细维度的聚合在hana里非常快(在XY,几个上亿的表jion再出报表,大部分都能控制在10秒内,说明只要我们能把条件压倒最底层,hana是可以保证处理速度是非常快)。
但是整合层还是需要。列几个需要整合层模型的要素:
1 对象存在多个关联关系,需要多次join或者多次处理才能得到
2 可能会被多次使用的逻辑
当然,需要我们对业务比较熟悉和对用户的诉求比较了解。
比如在LX的业务流有两种:
I Customer SO–>HOH PO–>Plant SO
II Custmer SO–>SD PO–>HOH SO–>HOH PO–>Plant SO
将这些数据整合到一个模型,供所其他有需求的地方使用,不用每个人都要写几个join才能得到而且性能一定不是最优,这样的一个小的模型(估计不到30个字段)即达到重复使用,而且性能绝对好。