• Les INNER JOIN sont généralement à préférer aux FOR ALL ENTRIES.
• La DB limite la taille des contraintes IN dans les clauses WHERE (le traducteur SQL écrit en fait des contraintes classiques avec des identités ou des BETWEEN, qui peuvent être très (très) longues). En général cette limite est d'ordre du millier (dépend de la longueur du champ).
• Sur une grosse requête, toujours mettre une contrainte sur au moins l'un des index de chaque table.
• Lors de la création des indexes, ne jamais oublier de mettre le champs MANDT… le kernel a beau gérer le champs MANDT en scred assez souvent (SELECT, champs de jointure, etc), il reste des cas où il faut tout de même citer explicitement le champs (par exemple lors d'un INNER JOIN, il faut sélectionner explicitement le champs mandant si on veut récupérer l'intégralité des champs de l'une des tables).

• Le LOOP AT .. WHERE passe par un optimiseur alors que pour le read table, ça doit être fait à la main avec le BINARY SEARCH.
• Si la table peut posséder une clé primaire unique, la déclarer en HASHED et faire les READ TABLE .. WITH TABLE KEY et les LOOP AT .. WHERE sur la clé.
• Si la table ne possède pas l'unicité de la clé, la déclarer en SORTED.
• Si la table est STANDARD, toujours la trier par la clé avant de faire un READ TABLE .. BINARY SEARCH ou un LOOP AT .. WHERE sur la clé.
• Si la table est SORTED ou HASHED, elle ne supportera pas les APPEND, il faudra utiliser des INSERT (avec le léger surcoût d'insertion du au tri ou à l'algo de hashage).

Le parallel cursor est une technique pour lire efficacement 2 tables internes liées par une jointure de type “entête-poste”. Elle consiste à optimiser les nested loops en passant par un read table binary search, prendre le sy-tabix, faire la nested loop FROM cet index et boucler jusqu'à ce que la clé change. Sauce