Another way of storing is EXPORT and IMPORT, with the option TO DATASET (a sequential file) TO DATABASE ( (to a special SAP table) and even TO MEMORY, "to R/3 work memory". This last option can be used to pass data in between successive transactions. Releasing the reserved memory can be done with FREE MEMORY or DELETE FROM DATABASE.
The EXPORT TO DATABASE statement needs a little extra: exporting data to the database is something that is not done too often. however, it's very convenient in some cases. If you want to store your data temporarily e.g. "simulation data", which stores information about the selection that will be picked up later. Or a concept like "Runtime analysis", where a certain dataset is stored just for reviewing. These temporary data sets will normaly be deleted afterwards. However, when they should be available for some days, storing them to the database is necessary.
The concept is quite simple: any data you hand over to EXPORT TO DATABASE will be stored in a transparant table. However, the way it is stored is not your business. Just make sure you retrieve it with IMPORT FROM DATABASE again. So what's the advantage !? Well, you don't have to set up a (or more) transparant table(s) for your data, you could "drop off" several internal tables or variabls into the same entry.
So where is it stored !? The statement takes a few parameters:
EXPORT obj1 ... objn TO DATABASE dbtab(ar) ID key. Your obj1 ... objn can be your internal tables or other data. The bit about dbtab(ar) is about which table it is stored in. However, you cannot use just any table, it should be a table like table INDX. The ID key is used as key field for retrieving your data, thus you could set up several datasets in your programs.
Looking at INDX, one of the fields in a very long "raw" field, in which your data will end up. You could use table INDX for your stuff, or you could look for another one like it by looking at the "where used" list for e.g. one of the key fields. The dbtab(ar) bit should be filled in as (e.g.) INDX(ZZ), which means: use table INDX with as main key field (RELID) the value ZZ. A good way to separate your stuff from the rest. If you like the concept, you could create a customer specific one and copy all the field from INDX in it !
Interface imaging - sending out only the delta of changes
A common problem in interfacing (and thus a common problem in general) is the delta. How can we make sure that changes are processed only when they were changes ? Working with a last changed date can be sufficient, but working with an interface image is more accurate. When the outbound interface record is composed and sent out, this record is also stored in SAP. As-is. When the interface report runs again, the same records is composed again and the result is compared to the version last sent out on the database. No differences = don't sent record. Differences = send record and update database. Simple, robust and very effective. Nothing is ever sent out if not needed, and all changes lead to an outbound interface record being sent.
All in all: why mention this here ? The EXPORT TO DATABASE logic is the perfect data storage method for this topic. There is only 1 report that needs to access this data, the format is irrelevant and the fact that the INDX table can't be read with the naked eye (SE16) is a great help. Note that you can compose your own version of the INDX table - with your own key fields. SAP's help text explains it nicely: press F1 on EXPORT, then TO medium, then DATABASE dbtar(ar)... and make sure you don't miss the link to structure.
Any alternatives to INDX ?
You can copy the definition of INDX to your own table (ZINDX) and thus ensure the use of the table is in your control. Alternatively you can "shop around" for other tables with a similar setup. I found 147 just by doing a where-used list on data element INDX_SRTFD amongst which:
CNDB, CVSE_INDX, COINT_INDX, DMC_INDX, GAPCLUST, INDX_ESS, INDX_VER, KLCLUST, MASSVARDAT, MASSVARDB, OIUGT_INDX