在传统 ABAP 项目里，有一种代码形态几乎伴随了很多开发人员整个职业生涯。程序通过SELECT从数据库读取数据，把结果放进 ABAP Internal Table，再通过LOOP、READ TABLE、SORT、COLLECT、DELETE等语句完成过滤、聚合、计算和业务加工。这样的代码非常符合传统三层应用架构的直觉。数据库负责保存数据。ABAP Application Server 负责业务逻辑。SAP GUI、Web Dynpro、Fiori 或其他前端负责与最终使用者交互。早期系统里，这套思路并没有明显的问题。数据库通常是整个系统中最昂贵、也最容易形成性能瓶颈的组件，因此应用程序往往尽可能让数据库执行简单 SQL，把复杂业务逻辑留给 Application Server。这就是经典的 Data To Code 思路。数据被搬到代码所在的位置，再由代码处理数据。在 SAP HANA 出现之后，这套曾经非常合理的设计哲学开始发生变化。数据库不再只是一个被动的数据存储仓库，而逐渐成为拥有强大计算能力的数据处理引擎。SAP HANA 的列式存储、内存计算、并行执行、复杂表达式、聚合能力以及 SQL Optimizer，使很多过去必须在 ABAP 层完成的计算，可以直接在数据库中执行。于是问题从过去的「怎样尽量减轻数据库压力」，逐渐变成了「既然数据库已经具备强大的计算能力，为什么还要把几百万条数据搬到 Application Server 再计算」。