Where-Bedingung

Siehe Schlüsselbefehl Select-Options.

In aller Regel sollten alle einschränkenden Bedingungen in die Where-Klausel aufgenommen werden. Die Datenbank kann so den Schlüssel oder Indizes nutzen und die Netzlast für die Übertragung von Datensätzen ist am geringsten.

Angabe Key-Felder / Sekundärindexfelder

• Selbst wenn die Datenmenge durch die Angabe eines Feldes nicht eingeschränkt wird (wenn immer der gleiche Wert im Feld steht), kann es eine Performanceverbesserung bringen dieses Feld in die Where-Bedingung zu füllen, wenn dieses Feld in einem Index (oder sogar im Primärkey) enthalten ist.

Where-Felder nicht übergeben

• Vorsicht bei einem Inner-Join welchen Weg der Datenbankoptimizer einschlägt, um die Datenmenge schrittweise zu verkleinern.
• In seltenen Fällen ist es vorteilhaft die Where-Bedingung um Bedingungen zu bereinigen, um die Datenbank dazu zu "zwingen", einen bestimmten Weg zu gehen, von dem man aufgrund der Datenmengen (über SE16) weiß, das er der optimale Weg ist - und dann die anderen Bedingungen außerhalb des Inner-Joins abzufragen.

Reihenfolge Where-Felder

• Sehr umstritten ist, ob es einen Performancevorteil bringt, wenn man die Select- und Where-Felder eines SQL-Statements in der Reihenfolge angibt, in der sie auf der Datenbank stehen. Ob das einen Vorteil bringt, hängt sicher von der Datenbank und dessen Release-Stands ab. Es hat mir jedoch ein fähiger Basisbetreuer versichert, dass das (in einer Oracle-Umgebung) sehr große Auswirkungen auf die Performance haben kann. Wenn z. B. die Felder in der Where-Bedingung nicht in der Reihenfolge angegeben sind, wie sie im Index definiert sind, könnte es passieren, dass dieser Index vom Datenbankoptimizer nicht gefunden wird.
• Eigene Erfahrungen, die die Relevanz der Reihenfolge der abgefragten Felder bestätigen, habe ich nicht. Schaden kann es sicher nicht, die Felder in der Reihenfolge anzugeben, in der sie auch in der Tabelle stehen.

Laufzeitfehler bei sehr vielen Select-Options/for all entries-Einträgen

• Sind Tausende Datensätze in einem Select-Options/Range, der in der Where-Bedingung abgefragt wird, bzw. in einer Tabelle mit "for all entries", kann es zu einem Laufzeitfehler „Der Open SQL command is too big“ kommen. Der String, der an die Datenbank übergeben wird, löst die Select-Options/Range-Einträge in Tausende Zeilen mit einer OR-Bedingung auf. Es gibt auf Datenbankebene eine Begrenzung der Länge dieses SQL-Strings. Diese Länge hängt von der Datenbank und vom Datenbankversionsstand ab.

Wenn abzusehen ist, dass ein Select-Options sehr groß werden kann, dann sollte man besser den Select auf eine Select-Endselect-Schleife umstellen oder die Datensätze in einem Loop abfragen. Die Datenbank wird gewöhnlich die internen Datenbankabfragen so optimieren, dass trotzdem eine hohe Performance bei der Gesamtabfrage ist, auch wenn die Gesamtabfrage in Tausende Einzelselects gesplittet wurde.

  DATA: lrt_objky TYPE RANGE OF nast-objky.

  IF s_objky IS INITIAL.
    SELECT *
      INTO CORRESPONDING FIELDS OF TABLE pct_itab
      FROM nast
      WHERE
       kappl  = p_kappl  AND "Applikation
       objky IN s_objky  AND "Objektschlüssel
       kschl  = p_kschl  AND "Nachrichtenart
       spras IN s_spras  AND "Sprache
       parnr IN s_parnr  AND "Partnernummer
       parvw IN s_parvw  AND "Partnerrolle
       erdat IN s_erdat  AND "Erstellungsdatum
       nacha IN s_nacha  AND "Medium
       datvr IN s_datvr  AND "Verarbeitungsdatum
       usnam IN s_usnam  AND "Benutzer
       vstat IN s_vstat  AND "Versandstatus
       vsztp IN s_vsztp.     "Verarbeitszeitpunkt
  ELSE.

    LOOP AT s_objky.
      CLEAR lrt_objky.
      APPEND s_objky TO lrt_objky.

      SELECT *
        APPENDING CORRESPONDING FIELDS OF TABLE pct_itab
        FROM nast
        WHERE
         kappl  = p_kappl   AND "Applikation
         objky IN lrt_objky AND "Objektschlüssel
         kschl  = p_kschl   AND "Nachrichtenart
         spras IN s_spras   AND "Sprache
         parnr IN s_parnr   AND "Partnernummer
         parvw IN s_parvw   AND "Partnerrolle
         erdat IN s_erdat   AND "Erstellungsdatum
         nacha IN s_nacha   AND "Medium
         datvr IN s_datvr   AND "Verarbeitungsdatum
         usnam IN s_usnam   AND "Benutzer
         vstat IN s_vstat   AND "Versandstatus
         vsztp IN s_vsztp.      "Verarbeitszeitpunkt

    ENDLOOP.
  ENDIF.