2022/09/07 BW模型设计

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个字段）即达到重复使用，而且性能绝对好。