Selects bzw. Inner Joins über mehrere DB-Tabellen

Selects bzw. Inner Joins über mehrere DB-Tabellen

Re: Selects bzw. Inner Joins über mehrere DB-Tabellen

  SELECT v_eq~zz_maschnum v_eq~typbz v_eq~zz_prodlinie v_eq~zz_prodtyp
         v_eq~zz_baureihe v_eq~zz_baugroesse v_eq~eqktx v_eq~equnr
         v_eq~tplnr v_eq~baujj v_eq~stort ifo~objnr ihpa~parnr
    from v_equi as v_eq 
    JOIN iflot as ifo on ifo~tplnr = v_eq~tplnr
    JOIN ihpa on ihpa~objnr = ifo~objnr
      INTO CORRESPONDING FIELDS OF TABLE gt_collect
        WHERE v_eq~equnr in so_sapnr
        and   v_eq~tplnr in so_saptp.

• Bei seinem ersten Auftreten ist das Feldsymbol <fs_collect> gar nicht ASSIGNED. Da fehlt irgendwas, vermutlich ein LOOP über die gt_collect.
• Die Aliases, die Du in Deinem Select gesetzt hast, halte ich für kontraproduktiv. Wenn Du die Zeichen abziehst, die Du für die Definition des Alias selbst brauchst, dann sparst Du bei v_equi nur wenige Zeichen. Bei iflot legst Du sogar drauf; das wäre ohne Alias insgesamt kürzer! Der Preis, den Du aber in jedem Fall zahlst, ist, dass Dein ganzer Select schlechter lesbar ist, weil man bei jedem Feld eben immer überlegen muss, aus welcher Datenbanktabelle es kommt, weil anstelle des Tabellennamens halt nur ein Aliasname davor steht. In meinem obenstehenden Beispiel habe ich noch die ihpa mit drangejoint und dafür keinen Alias verwendet, und das liest sich prima, finde ich.
  
  Aliases benutze ich nur dann, wenn ich dieselbe Tabelle mehrfach in unterschiedlichen Rollen in ein- und demselben Select benötige. Dann geht es nicht anders, und dann kann man den Aliasnamen nutzen, um deutlich zu machen, in welcher Rolle man sie gerade verwendet. (Ein gutes Beispiel für eine Tabelle aus dem HCM, bei der man sowas brauchen kann, ist die HRP1001.)
• Die Klammer in Deinem Select ist unnötig. Das System braucht sie nicht, und für den Leser gliederst Du besser durch Zeilenumbrüche.
• Deine ganzen FOR ALL ENTRIES sind gefährlich, weil Du vorher nicht prüfst, ob die interne Tabelle leer ist. In diesem Fall würde der FOR ALL ENTRIES Dir ganz böse um die Ohren fliegen, weil der Select dann komplett ohne WHERE-Bedingung ausgeführt wird (also die gesamte Zieltabelle findet)!
• Der Block

  Code: Alles auswählen.

        READ TABLE gt_ihpa INTO gs_ihpa with KEY objnr = <fs_collect>-objnr.
        if sy-subrc = 0.
          <fs_collect>-parnr = gs_ihpa-parnr.
        ENDIF.

  gefällt mir nicht, denn er ist oldschool. Du kannst den ganzen Block durch eine einzige Zeile ersetzen:
  

  Code: Alles auswählen.

  <fs_collect>-parnr = VALUE #( gt_ihpa [ objnr = <fs_collect>-objnr ]-parnr OPTIONAL ).

  Der einzige funktionale Unterschied zu Deinem Code ist, dass <fs_collect>-parnr in diesem Falle auf Initialwert gesetzt werden würde, wenn es die entsprechende Zeile in der gt_ihpa gar nicht gibt. Bei Deinem Code dürfte das aber keinen Nachteil darstellen. Zugleich kannst Du Dir damit die Definition der ganzen Ballast-Workareavariable gs_ihpa (also den entsprechenden DATA-Befehl) komplett sparen.
  
  Wenn Du die neue Schreibweise als schlecht lesbar empfindest, dann liegt das daran, dass Du sie nicht gewohnt bist. Am Anfang ging mir das auch so. Man sollte sich gegen Neuerungen aber nicht sperren und in veralteter Denke verhärten. Wenn Du mit der neuen Schreibweise rumspielst und sie Dir antrainierst, dann wirst Du sehr bald merken, dass sie sogar besser lesbar ist als der alte Kram und wirst sie nicht mehr missen wollen. Sich bei Tabellenzugriffen die blöden Workareafelder sparen zu können, ist ein Riesenvorteil!

Re: Selects bzw. Inner Joins über mehrere DB-Tabellen