Choosing the Right Table Type

Explanation

Match table type to access pattern. STANDARD with SORT + BINARY SEARCH is fine for one-shot batch loads. SORTED keeps order on insert and gives fast range access. HASHED is ideal when you look up single rows by unique key many times. Secondary keys let one internal table serve multiple access paths without duplicating memory.

Code example

DATA lt_mara TYPE HASHED TABLE OF mara WITH UNIQUE KEY matnr     WITH NON-UNIQUE SORTED KEY by_matkl COMPONENTS matkl.READ TABLE lt_mara WITH TABLE KEY matnr = lv_matnr ASSIGNING FIELD-SYMBOL(<m>).LOOP AT lt_mara USING KEY by_matkl WHERE matkl = lv_matkl ASSIGNING <m>.ENDLOOP.

Real project scenario

A pricing report used LOOP AT + WHERE on a 2M row table. Switching to SORTED with a matching secondary key cut runtime from 40 min to 90 s.

Common mistakes

Adding BINARY SEARCH without sorting first; using HASHED for range access; unnecessary DEEP secondary keys.

Best practices

Design keys before writing the LOOP. Prefer WITH EMPTY KEY when no key is used, so accidental READ never returns the wrong row.

Interview angle

Explain when a secondary sorted key beats sorting a copy of the table.