The system relies on it's data, and data needs to be selected. SAP has implemented SQL (Structured Query Language) in it's ABAP to answer to the data selection requirement. SELECT * FROM vbap WHERE ... in short, but check these articles for the longer versions.
The internal table is an Abap language component that is used very often. Whenever information is needed in repetitive form, the internal table is used. You will not find many reports that have no internal tables, and they have been around since the earliest Abap versions.
Processing an internal table is done in an Abap specific way. With internal tables, a work area is required. Actual changes are done on the fields in a work area, which can be appended (APPEND) at the end of the internal table or inserted (INSERT) at a given position (by specifying an index number). Since internal tables play such a big big role in Abap reporting, check out this article internal table specifics. Here's a listing of actions you can do to your internal table:
An internal table is very handy, but you may want a table with tables or "table-in-table". Which is no big deal at all. How are they defined, what to do about the message: "YOUR_TYPE" is a generic type. Use of this type is only possible for typing field symbols and formal parameters.". Some examples:
The SELECT statement is kind of a big deal in ABAP programming. SAP sits on a database server and the SELECT statement serves data into ABAP. It's is the main and only channel in fetching data, so it is good to know a thing or 2 about it. In it's simplest form:
TABLES: mara. SELECT-OPTIONS:
so_matnr for mara-matnr. SELECT * FROM mara WHERE matnr IN so_matnr. * Do something with the result ENDSELECT.
The above example selects all available fields (*) from table mara (The material master) for which the material number (matnr) is specified in range variabele (select-options variabele) so_matnr. Note that the actual select statement is a loop, ending with ENDSELECT.
The JOIN addition on SELECT allows you to merge several data tables together into a single result or result table (mostly). As database servers are quite clever bits of machinery, using a join is not only nice coding, it can be very helpful in a good performance too.
A simple example:
SELECT hdr~vbeln itm~posnr
itm~matnr FROM vbuk AS hdr INNER JOIN vbup AS itm ON hdr~vbeln = itm~vbeln INTO TABLE gt_results WHERE hdr~vbeln in so_vbeln.
When a JOIN is used, the soul purpose wil be involving multiple tables in a single select action. The result will most likely be an internal table with columns from several tables. You can set up your internal table with fieldnames that do not match the fieldname in the original table - see the example:
If your system supports multiple clients, you can access data from the "other" client as well. For client-dependent tables that is. A short example of CLIENT SPECIFIED.
Execute a SELECT statement as part of your SELECT statement - the subquery through IN.
This is not very common, but in some cases table structures can hold a repetition of values in a single row. Thus a record from the transparent table holds columns with similar information. An example would be from HR: table PA0008 also known as Infotype 8. This table has fields called LGA01, LGA02, LGA03 ... LGA40 The VARYING option on the DO .. ENDDO statement can be a great help here.
The SELECT statement can also be used in a dynamic way. The list of fields, the actual WHERE clause and the table name can all be defined at runtime. This is not very common and maybe even difficult to read (for your fellow developers) but it is a powerful option that you do need to know about. If not to implement yourself, this article can clarify how dynamic selects work.
If your report/program does not select data, it's development is probably not finished. If your programs selects great amounts of data, it will probably be slow in performance. Other than making sure the data itself is selected efficiently (check the articles on performance tuning) there is another fact on data selection. Whenever a selection is done, a communication channel to the database server is opened, the request is "handed over" and the results are received. That's quite a suite of actions, which are all taken care of by the system.
Know this: if you scatter selection logic all over your report, the communication channel will close or fall asleep. A few nano seconds later your new request comes in and the system will need to wake up, have some tea, start up connections and get the show on the road again. All of this is consuming valuable performance time. Thus: select all you need and work with what was selected. Ideally.