ABAP_to_the_Future

2
New Language Features in ABAP 7.4
buffering in table DDIC to dramatically reduce the database access, thus making
the program run much faster and cheering up my users. Although buffering has
been around for a long time, there have also been some problems with it; mainly,
that there are a whole raft of situations in which the buffer is bypassed and you
don’t get any performance improvement at all. (You can mitigate this problem by
using the Code Inspector. If you run a Code Inspector chec k on your program
after creation and after every subsequent change—which you should always do—
you get alerted to any such database reads you may have coded in the expectation
that the buffer would be used.)
To demonstrate a common situation wher e the buffer is bypassed, consider an
example where half of your queries get data from the table ZT_MONSTERS using the
MONSTER_NUMBER (which is the primary key), and the other half get data using the
MONSTER_NAME (on which you have an index). As sume that this is a master data
table that is relatively small, read often, and rarely changed—so naturally you’ve
defined it as fully buffered in the technical settings.
If you perform a SQL query using MONSTER_NUMBER, then no database access happens
at all (after the first read after the database is started), because you have specified
the primary key in your query. However, if you perform a SELECT SINGLE
using MONSTER_NAME, then the Code Inspector warns you that table buffering will
not be used, because you’re not specifying the primary key.
People used to get around this by reading the whole table from the database into
an internal table and then sorting it by MONSTER_NAME. Then, whenever someone
wanted to find a monster by name, he’d perform a BINARY SEARCH to get the
desired record. Before 7.02, people sometimes used to have two (or more) internal
tables, sorted differently based on different keys. As of 7.02, you can have secondary
indexes on internal tables, and so you only needed one table. However,
that’s still one table too many from a memory-consumption perspective.
As of release 7.4, this is no longer a problem. If you perform a SELECT SINGLE on
MONSTER_NAME and then run an ST05 performance trace, you will not see any database
access at all, even though you didn’tspecify the primary key. This is because,
as of 7.4, if you’ve defined a secondary index on MONSTER_NUMBER in table ZT_MON-
STERS, then that index is magically taken into account as well. Secondary indexes
are taken into account not only on fully buffered tables but also on generically
buffered tables, which is a giant leap forward performance wise. Buffers taking
86