ABAP_to_the_Future

Other Modifications to ABAP for SAP HANA 15.5
All of this has three implications for what you need to do when designing ABAP
programs:
왘 First, you no longer need to add redu ndant fields to any new database tables
that you create for the sole purpose of improving performance.
왘 Next, due to the absence of such redundant storage fields, you don’t have to
spend any time considering which table to get any given piece of data from,
because it will only be in one place. For example, in th e traditional way of
doing things, you might have to query both BSID and BSAD—because you
know a database record exists in one of these tables, but not in which one.
왘 Finally, because there are fewer (hopefullyno) redundant fields in transactional
tables, you’ll need to read more master data tables to fill in the blanks with
information such as the material group for a material.
Avoiding Inefficient Retrieval of Master Data
It has always been (and still will be, in the SAP HANA world) a no-no to do an inner join
between transactional data and master data. This is because there’s no point in having
100 sales order lines all with the same material group joined with the material master;
the result would be the same for each line.
Such a query would be a lot faster with SAP HANA, but it still would not be a sensible
thing to do. Just because the extra database access time is now negligible, that’s no
excuse for abandoning common sense! (Thoug h I suspect a lot of people will do just
that.)
Secondary Indexes
In traditional SAP database tables, the primary key is often some sort of number:
sales order number, material document number, monster number, and so on. In
more modern SAP database tables (e.g., BOPF, BRFplus, etc.) the primary key is
some sort of GUID. That’s wonderful if you happen to know the sales order number
or the GUID, but more often than not you don’t. Database queries are usually
along the lines of “Give me all the sales orders for customer Joe Bloggs for May”
or “Give me all the monsters named Fred who went on a rampage in June.”
Doing a database SELECT on a field other than the primary key would have caused
a full table scan, and so you would have created secondary indexes on such fields
as customer number or monster name. This made data retrieval very fast, but the
downside was twofold: Every time a reco rd was saved, ther e was an additional
overhead of updating the index, and in some tables with lots of indexes, the stor-
693