2022/03/31 Hana Scripted CV

hana从sp11开始建议脚本视图转为图形视图，先将脚本用table function封装，再在图形cv里调用TF。为什么这样改？有什么好处？我现在还没有看到文章讨论。

1 性能 现在我们的系统大部分CV都是脚本，很少有图形化的CV，图形化的CV有个最大的问题，若逻辑有rank，max这种聚合类的计算，性能下降的很快，这个问题在sdn上很多人都遇到了，大多都是通过脚本来解决。有人测试过用图形的rank和脚本的rank语句，一个是15秒，一个是5秒。在我们这里有很多报表也证明了脚本在处理这种逻辑，性能非常好。TF虽然也是代码，他的性能和脚本cv差不多，至少我测试了一个对象，脚本视图需要大概20多秒的，TF也是20多秒，并没有明显的提升

2 调试 脚本（sql procedure）是可以直接调试的，但是TF在hana studio是不能调试的。至少在我们现有的版本是这样，我查了很多资料，要么用 web ide，要么手工改成store procedure再调试。太蛮烦了，不如直接创建scripted CV

3 管理 好像脚本视图不太容易管理，生成的对象也多，但是熟悉了也还好。如果对象多了，图形视图也是蜘蛛网，也不好管理。

可能在hana 2.0里，当bas有个人版或者本地版（估计2023.Q1发布），我估计大多数开发工作会在bas里完成，这时用TF的方式可能是比较合适的。这个等以后有机会使用hana 2.0的时候，我再来更新。

-------------------------2022/09/25 更新------------------------------------

现在还经常听到有人说，不要用脚本而是图形拉线。我只能说坚持这点的人，没有长期做过模型运维工作。每天对着一大堆蜘蛛网的节点，找个问题，需要几次preview，一层层跟踪，舒服吗（我不太喜欢浪费时间）？而且遇到复杂逻辑（例如有ranke，join有大小关系比较等），绝对是脚本方便，性能快。如果有一套好的管理架构，命名规范，代码注释，运维难度应该可控，同时也能满足很多用户需求。
参考性能测试的文章：
https://blogs.sap.com/2018/12/11/rank-function-performance-issue-in-hana/