Internal tables are temporary in-memory data structures used throughout ABAP programs. Developers use them to hold query results, transform business data, prepare reports and exchange collections between methods. Choosing the correct table category and key can make code clearer and prevent slow searches.
The goal is not to select a hashed table every time performance is mentioned. The access pattern should determine the design.
Standard tables
A standard internal table is index-based and works well for sequential processing or appending rows. Access by index is efficient, while repeated key searches can become expensive as the table grows.
Use a standard table when order matters, most processing is loop-based or the dataset is small enough that complex optimisation would reduce readability. If key reads become frequent, consider a suitable secondary key or different table category.
Sorted tables
A sorted table maintains rows in key order. Key access uses the sorted structure, and the table is useful when code needs both ordered looping and efficient reads by the leading key components.
The key can be unique or non-unique. Inserts occur in sorted position, so developers do not control an arbitrary index. Define a key that reflects the actual lookup and grouping behaviour.
Hashed tables
A hashed table is designed for fast key-based access through a unique key. It has no meaningful primary index and is not chosen for index operations or ordered output.
Hashed tables suit lookups such as retrieving configuration by company code or finding a master record by identifier. They are less suitable when range access or sorted traversal is required.
Define explicit keys
Avoid relying on an unclear default key. Explicit primary and secondary keys tell readers how the table is meant to be accessed. A secondary sorted or hashed key can support additional patterns without duplicating the table, but it also consumes memory and maintenance work.
Measure before adding many keys. Optimisation should target actual data volume and execution paths.
Read and update safely
Modern ABAP provides table expressions alongside READ TABLE. Whichever syntax is used, handle the not-found case. A failed table expression can raise an exception if optional or default handling is not applied.
Use field symbols or references when appropriate to avoid unnecessary row copying. Keep code readable and understand when changing an assigned row updates the internal table directly.
Avoid nested-loop performance problems
Looping over one large table and performing a full scan of another can create rapidly growing runtime. Replace repeated searches with a keyed lookup, sort and use binary search correctly, or redesign the data retrieval.
Do not fetch an excessive dataset from the database merely to filter it in ABAP. Push suitable filters and aggregation to the database, then use internal tables for application-level logic.
Common operations to practise
Learn appending and inserting rows, VALUE constructions, CORRESPONDING, filtering, reducing, grouping loops and duplicate removal. Understand how sort order affects DELETE ADJACENT DUPLICATES.
Practise converting a database result into a lookup table and using it to enrich another dataset without queries inside a loop.
Project exercise
Build a sales-report program that loads header and item data, creates a customer lookup, aggregates values and outputs a sorted summary. Implement standard, sorted and hashed alternatives for one lookup and compare readability and runtime using realistic volume.
Build core programming and reporting skills through the SAP ABAP Training in Vizag. Combine the correct in-memory structure with efficient ABAP Open SQL and display prepared results using an ALV report.
Final takeaway
Use standard tables for sequential and index-oriented work, sorted tables for ordered key access and hashed tables for unique lookups. Explicit keys and realistic performance tests are more valuable than blanket rules.