HANA Pushdown with Open SQL, CDS and AMDP

Explanation

On HANA, performance tuning often means pushing suitable filtering, joining, aggregation and calculations to the database. Modern Open SQL, CDS views and AMDP can reduce data transfer and improve performance for large datasets. However, not every logic should be pushed down. Complex business rules, authorization-sensitive logic or low-volume processing may remain cleaner in ABAP. The goal is not to use CDS or AMDP everywhere, but to reduce unnecessary data movement and let the database handle set-based operations where appropriate.

Code example

* Bad pattern:* Fetching huge data into ABAP and aggregating there. SELECT kunnr, netwr FROM vbrk INTO TABLE @DATA(lt_billing) WHERE fkdat IN @s_fkdat. * ABAP aggregation would happen here. * Better pattern:* Push aggregation to database using GROUP BY. SELECT kunnr, SUM( netwr ) AS total_value FROM vbrk INTO TABLE @DATA(lt_customer_total) WHERE fkdat IN @s_fkdat GROUP BY kunnr. * Benefit:* Less data transferred to ABAP and less memory usage.

Real project scenario

A report fetched 5 million line items into ABAP and then aggregated by customer. Replacing this with DB-side GROUP BY reduced memory usage and runtime drastically.

Common mistakes

- Fetching all rows then aggregating in ABAP. - Using AMDP for simple logic that Open SQL can handle. - Ignoring authorization and business readability. - Assuming HANA fixes bad SELECT design automatically.

Best practices

- Push filtering and aggregation to DB. - Use Open SQL before AMDP where sufficient. - Use CDS for reusable semantic models. - Keep business logic maintainable.

Interview angle

Architect-level answer should explain pushdown for set operations, not blindly moving all logic to DB.