Comments
SAP PERSISTENT DATA STORAGE GUIDL documentation, setup help and example usage
GUIDELINE 5.2
Persistent Data Storage
ABAP_BACKGROUND
ABAP programs can have both read and write access to data in the following persistent storage media:
According to the SoC principle , such accesses are wrapped in service classes of the persistency layer of an application.
ABAP_RULE
Plan persistent data storage carefully
Select with care the persistent storage media that are used by the application as well as the possible data transport routes between these media. Here is a general rule of thumb:
ABAP_DETAILS
When you plan persistent data storage, you should follow these steps:
On an AS ABAP , storing in relational database tables is always the first choice. ABAP supports this with the Open SQL that is integrated into the language. An object-oriented access is possible using Object Services. The majority of the data is stored in the central standard database of the application server. You can access additional databases by using secondary database connections (managed using the DBA Cockpit ).
The following data can be stored in data clusters when using the
EXPORT and IMPORT statements:
- Formatted data as the result of comprehensive analyses
- Data that is not suitable for relational databases because it does not exist in the first normal form (such as nested internal tables)
- Object networks after a serialization to XML
The persistent storage of data in files of the application or presentation server is usually the least suitable for AS ABAP application programs because it is generally platform-dependent (codepages, byte order). In addition, such data is then only available on a particular application server, which can be problematic in a load distribution scenario with automated server selection. Such files may be required for the data exchange with external systems, however.
Under no circumstances should you use existing database tables (or files) to store data that are not provided for this purpose. Follow the convention of restricting reads and writes to database tables to specific packages. A database table must always be considered a semantic entity that is only allowed to contain the corresponding data. This even applies if a table with the required structure already exists. If in doubt, you should create a specific database table.
You must also be careful when using seemingly cross-system resources, such as the predefined INDX database table, to store data clusters. Such a resource must only be used to store temporary data for the short term, if at all. You should create specific database tables, for example, INDX -type tables, for application-specific and longer-lasting data.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved
