Traditional ABAP Programming style is more inclined towards reducing the load on Database and shifting the processing to Application server. This is more to do with Data Storage models and SAP 3-tier system architecture provided another layer for data processing. This restricted ABAP developers to confine to the concept of “pulling required data to Application server and processing data in App Server” and along came the complexities of buffering.
With the introduction of HANA, data is available in volatile memory so data can be retrieved and processed in same “memory”. At first thought, this gives a feeling that ABAP OpenSQL Programming style should be changed and some of the “banned” OpenSQL statements like ‘Order By’ etc should come back in to use. Well, Hold on!! Let’s not jump into conclusions, let’s analyze some specific scenarios from HANA perspective and decide on this –
Scenario-1: There is a database table with 50 records in it and you wish to read the table 1000 times for values based on field F1.
· Non-HANA: Since the database table is relatively small in size, make a copy of the table in your program and then read the desired record as and when required.
· With HANA: Read data from database table as and when required and process it. Remember, with HANA query and data processing is happening at the same place!!!
Scenario-2: Let’s consider opposite scenario to Scenario-1. There is a database table with 10000 records in it and you wish to read the table 100 times for the values based on field F1.
· Non-HANA: Since the database table is very large, it’s better to use SELECT SINGLE than porting the entire table into an internal table.
· With HANA: Same as in Non-HANA read data from database table as and when required and process it. The only advantage here is there is no network traffic with every query as query and data processing is happening at the same place!!!
Scenario-3: Joins Vs Nested Select statements
· Non-HANA: Join is the most preferred way to fetch data from two tables instead of nested select statement. No second thoughts about it from OpenSQL perspective.
· With HANA: Join has its own advantages and Nested select has its own advantages from Relational database perspective. With HANA, the decision to use Join Vs Nested select statement depends on further requirements. If any intermediate processing has to be done, nested select is better than join.
Scenario-4: Optimize the cost of database searches
· HANA or No-HANA, the cost of database search should always be optimized and concept of index is extremely important
Scenario-5: Table buffering
· SAP provides buffering facility to increase performance. Since buffers reside in Application server it takes considerably less time to read data locally than reading it from database.
· With HANA, no additional table buffering is required as all the database resides in volatile memory.
Scenario-6: ABAP Sort Vs Order by clause
· Non-HANA: Optimized solution is to use ABAP Sort and reduce load on Database server
· With HANA: It really doesn’t matter. Both the statements should be equally good or bad.
