ABAPbeginner
Internal Tables & Table Operations
Working with ABAP's core in-memory data structure for processing sets of records efficiently.
Internal tables are the workhorse of ABAP - almost every report, BAPI, or Fiori backend service ends up looping over one. Interviewers use this topic to gauge whether a candidate understands performance implications, not just syntax, because the same task can be written in a way that is instant or a way that brings down a production system when the data grows.
A standard table is a stack of index cards in the order you dropped them in; a sorted table is a card catalog always in alphabetical order; a hashed table is a phone directory app that jumps straight to the entry by name with no scanning at all.
Key Concepts
1
ABAP supports three table types: standard tables (unsorted, indexed access is fastest by index but linear by key), sorted tables (always kept in key order, binary search lookups), and hashed tables (unique key, O(1) hash lookup, no index access). Choosing the right type for the access pattern is a classic interview discriminator - a hashed table used for a huge lookup-heavy dataset can turn an O(n²) nested loop into effectively O(n).
2
Equally important are the operations: READ TABLE ... WITH KEY versus WITH TABLE KEY versus binary search, LOOP AT ... WHERE, and modern functional constructs like FILTER, REDUCE, and table expressions (itab[ key = value ]). Candidates should be able to explain why nesting a READ TABLE inside a LOOP AT over another table is the single most common ABAP performance bug, and how to fix it using sorted/hashed tables or by using FOR ALL ENTRIES at the database level instead.
READ TABLE ... WITH KEYWITH TABLE KEYLOOP AT ... WHEREFILTERREDUCE
3
Control-break processing (AT NEW, AT END OF, SUM) and table comparisons round out what's expected of an intermediate ABAP developer working with internal tables daily.
AT NEWAT END OFSUM