水的数据库之道，老子一句话照进 SAP HANA 开发现场

早上坐在一个 SAP HANA 性能问题前，最容易看到开发者心里的执念。一个复杂的报表跑慢了，大家第一反应往往是加更多 Calculation View，写更长 SQLScript，塞更多中间表，或者在 ABAP 侧补一层缓存。看起来每个人都在「做事」，系统里也多了很多对象，可响应时间并没有明显下降。甚至更糟，原来一条 SQL 能被 SAP HANA 优化器顺畅改写和下推，现在被一段命令式过程、一个无谓的中间结果、一个过早的聚合挡住了，数据流像水遇到乱石，开始回旋、淤积、发臭。

老子说「水善利万物而不争，处众人之所恶，故几于道」。这句话放到 SAP HANA 开发里，讲的不是柔弱，也不是退让，而是一种非常高级的工程判断。好的 SAP HANA 开发，不是到处显示存在感，而是让数据在最短路径、最低摩擦、最接近计算资源的地方完成该完成的事。水利万物而不争，落到技术上，就是模型服务业务，但不抢业务语义的主角。水处众人之所恶，落到工程上，就是愿意处理那些没人愿意碰的底层问题，数据质量、基数估算、过滤下推、Join 裁剪、分区策略、冷热数据、Plan 分析、权限边界、传输治理。故几于道，落到系统生命力上，就是代码少一点炫技，多一点顺势。

SAP 自己对 SAP HANA Cloud 的描述里，强调它是支持多模型处理的数据库，可以在内存或磁盘上处理不同形态的数据，并服务于混合和多云场景；SAP 官方产品页也把 SAP HANA Cloud 描述为支撑任务关键型方案的数据库，具备关系、文档、地理空间、知识图谱、向量、时间序列等多模型能力。这个背景很重要，因为 SAP HANA 不是一个只会存表的传统数据库，它更像一条有多个支流的水系。关系模型是主河道，Calculation View 是水渠，SQLScript 是闸门，Graph、Spatial、J