ABAP_to_the_Future

Other Modifications to ABAP for SAP HANA 15.5
if not, then use an AMDP). In every case, the idea is to do work you would have
normally performed on the application serv er (like filtering ou t records) on the
database.
15.5 Other Modifications to ABAP for SAP HANA
Regardless of how much or little code pushdown you end up doing, there are
some further changes you need to make to your ABAP program design to get the
most out of your shiny new SAP HANA database.
This is rather like when electric ligh t and central heating were invented: The
architects could have kept on designing houses with big candelabras on the ceiling
and huge open fireplaces, and sometimes this is still appropriate (e.g., for the
baron’s castle)—but not fo r one-bedroom apartments. You have to change the
way you build things to take advantage of the new technology.
We programmers spend an awful lot of time worrying about performance, which
influences the design of both our programs and any Z database tables we create,
and such performance-related features need to be examined to see if they are
really appropriate anymore once we’re in the SAP HANA world. In this section,
you’ll learn three ways yo u should adjust your ABAP coding to account for SAP
HANA: the way you design your database tables, the way you avoid coding database-specific
features, and the way yo u make changes to databases using SELECT
statements.
15.5.1 Database Table Design
There are two major ways that SAP HANA changes how you will design database
tables; one has to do with redundant storage and the other with secondary
indexes. Each of these is discussed next.
Redundant Storage
From the time SAP was first created to the present day, ABAP developers have
often been forced (for performance reason s) to store the same data redundantly
in many different places. This of course means that the total space occupied by
the database is much larger than it needs to be.
691