以水胜刚，SAP HANA 开发里的柔弱之道

老子说「天下莫柔弱於水。而攻坚强者，莫之能胜。」这一句放到 SAP HANA 开发里，我会把它理解成一种很朴素的工程直觉，系统里真正强大的东西，往往不是堆得最厚的过程代码，不是最长的 SQLScript，不是最复杂的 Calculation View，也不是到处加索引、到处建中间表、到处写强制性逻辑的硬推。真正有穿透力的设计，更像水，它顺着数据的形态走，顺着 HANA 执行引擎的能力走，顺着业务变化的缝隙走。它看起来不逞强，却能绕过坚硬的阻塞点，渗透到性能瓶颈最深处。

在 SAP HANA 的世界里，所谓「坚强者」，经常表现为三类东西。第一类是僵硬的数据模型，表结构很厚，字段很多，关联很死，计算层一层压一层，业务一变，模型就要大修。第二类是僵硬的过程式代码，把本来可以交给优化器和列式引擎处理的集合运算，写成一段段循环、临时表、分支和手工拼装。第三类是僵硬的性能治理，遇到慢查询就加索引，遇到大表就拆表，遇到报表慢就复制一份宽表，短期似乎见效，长期却把系统变成很难调、很难迁移、很难解释的硬壳。

水的开发方式不是软弱无能，而是不和数据库引擎抢力气。SAP HANA 的 SQLScript 本来就是为了把数据密集型应用逻辑嵌入到 HANA 中执行，SAP 官方文档也把 SQLScript 描述为 SAP HANA 的 SQL 扩展，用于在数据库中承载数据密集型逻辑。这个方向本身就是一种「以柔入刚」，不是把所有数据拉回 ABAP 应用服务器再逐行处理，而是把计算推近数据所在之处，让数据库引擎用集合、并行、列式扫描、计划优化去完成大部分工作。(