Felder vergleichen (E-Mails in einer Tabelle)

Re: Felder vergleichen (E-Mails in einer Tabelle)

Also ein kurzer Code, der das von Dir gewünschte erreicht, wäre der hier:
Allerdings weiß ich nicht, wie intelligent die Datenbank mit dem SELECT umgeht. Da die ADR6 auf dem Feld SMTP_ADDR keinen Index hat, könnte es sein, dass er für jeden Eintrag in der internen Tabelle KUNDENSTAMM sequenziell durch die ganze Tabelle ADR6 sucht und das Ergebnis extrem langsam ist. In diesem Falle müsstest Du die relevanten Spalten der ADR6 zunächst komplett in eine interne Tabelle einlesen (so dass Du einmal einen sequenziellen Zugriff hast) und dann im LOOP immer nur mit READ TABLE TRANSPORTING NO FIELDS in dieser Tabelle nachlesen. Optimalerweise verwendest Du dafür eine Tabelle vom Typ HASHED.

Re: Felder vergleichen (E-Mails in einer Tabelle)

Ah, mir war nicht klar, dass bei den übrigen Ansprechpartnern dennoch die Adressnummer gleich sein soll. Ich dachte, Du wolltest einfach irgend jemanden anderen suchen, der die gleiche Emailadresse hat. So hast Du natürlich keine Probleme mit dem Index mehr.

Irgendwelche Anmerkungen dazu, was kann ich besser machen (Performance, Joins, usw.)?

Dein Code wird im Prinzip funktionieren, auch wenn SELECT-ENDSELECT-Blöcke, obwohl meines Wissens nicht offiziell deprecated, als schlechter Stil angesehen werden. Üblich ist, eine passende interne Tabelle zu definieren, in die man mit dem ersten SELECT per Zusatz INTO TABLE die Ausgangszeilen reinfüllt, um anschließend darüber einen LOOP zu machen. Das ist performanter, als wenn Du Dir die Ergebniszeilen einzeln aus der Datenbank holst.

Bei dem letzten Deiner drei SELECTs hattest Du die Schlüsselfelder in der falschen Reihenfolge in der WHERE-Klausel aufgeführt. Performance sollte Dich das zwar nicht kosten, da die Optimierer moderner Datenbanken pfiffig genug sind, das zu erkennen und sich die Felder entsprechend umzustellen, aber ich empfehle auch der besseren Lesbarkeit wegen, Schlüsselfelder stets in der Reihenfolge aufzuführen, in der sie im Index (in diesem Fall: im Primärschlüssel) stehen. Dann siehst Du auch leicht, wenn in der Mitte eins fehlt (was sofort dazu führt, dass die danach folgenden Felder nicht mehr für die Suchoptimierung genutzt werden können, weswegen man sich bemühen sollte, Schlüsselfelder lückenlos anzugeben, auch wenn in der Mitte triviale Felder dabei sind, von denen klar ist, dass sie immer nur einen bestimmten Wert haben werden. Ein typisches Beispiel ist die PA0001, wo man normalerweise Sätze anhand von Personalnummer und Beginn/Endedatum draus liest, dabei aber auch SUBTY, OBJPS und SPRPS (alle immer SPACE) angeben sollte. Schau Dir die Tabelle mal in der SE11 an, dann siehst Du, was ich meine).

Ein JOIN ist letztlich auch nichts anderes, als mehrere SELECTs in einem abzuwickeln. Aber gut, wenn wir JOINs als akzeptabel ansehen und eine EXISTS-Klausel, die sich in Deinem Fall förmlich aufdrängt, nicht, dann hätte ich noch ein paar kleinere Verschönerungen an Deinem Code zu bieten, die Du sicherlich selber erkennen wirst, wenn Du meine folgende Version durchschaust:

Re: Felder vergleichen (E-Mails in einer Tabelle)

ChrissixD hat geschrieben: Jetzt frage ich mich nur noch was das "SKIP." am Ende des Codes macht, weil das Programm ja beim Check schon aus der Schleife springt, wenn nichts gefunden wird

"SKIP." <---- <F1>

Syntax

SKIP { [n]
| {TO LINE line} }.



Varianten:

1. SKIP [n].

2. SKIP TO LINE line.



Wirkung

Positionierung des Listen-Cursors relativ zur aktuellen Zeile oder in einer beliebigen Zeile.



Variante 1

SKIP [n].




Wirkung

Diese Anweisung positioniert den Listen-Cursor relativ zur aktuellen Zeile. Die neue Zeile wird durch den Wert von n bestimmt. Für n wird ein Datenobjekt vom Typ i erwartet. Wenn der Wert von n kleiner oder gleich 0 ist, wird die Anweisung ignoriert. Wenn n nicht angegeben ist, wird die Anweisung so ausgeführt, als sei n mit dem Wert 1 gefüllt.

Die Positionierung erfolgt folgendermaßen:
• Wenn die Zeile des aktuellen Listen-Cursor durch eine Ausgabeanweisung (WRITE, ULINE) gesetzt wurde, wird der Listen-Cursor an die erste Stelle der Zeile gesetzt, die im Abstand von n Zeilen unter der aktuellen Zeile liegt.


• Wenn die Zeile des aktuelle Listen-Cursor durch eine Positionierungsanweisung (BACK, NEW-LINE, NEW-PAGE, SKIP) gesetzt wurde, wird der Listen-Cursor an die aktuelle Stelle der Zeile gesetzt, die im Abstand von n minus 1 Zeilen unter der aktuellen Zeile liegt.


Weiterhin gelten folgende Besonderheiten:
• Falls der Listen-Cursor nicht auf der aktuellen Seite positioniert werden kann, wird eine neue Seite erzeugt, wobei der eventuelle Seitenfuß der aktuellen Seite ausgegeben wird. Der Listen-Cursor wird in der ersten Stelle der ersten Zeile unter dem Seitenkopf der neuen Seite positioniert.


• Die Anweisung wird nur dann am Beginn einer Seite durchgeführt, wenn diese Seite die erste einer Listenstufe ist oder sie durch die Anweisung NEW-PAGE erzeugt wurde.




Hinweis

In den meisten Anwendungsfällen wirkt diese Variante der Anweisung SKIP einfach so, als würde sie n Leerzeilen erzeugen. Dabei ist aber zu beachten, dass solche Leerzeilen keinen Inhalt haben, der durch die FORMAT-Anweisung formatiert werden kann. Formatierbare Leerzeilen können nur durch die WRITE-Anweisung in Kombination mit SET BLANK LINES ON erzeugt werden.



Variante 2

SKIP TO LINE line.




Wirkung

Diese Anweisung positioniert den Listen-Cursor in der ersten Stelle der Zeile der aktuellen Seite, deren Nummer durch den Wert in line bestimmt wird. Für line wird ein Datenobjekt vom Typ i erwartet. Falls der Wert von line kleiner oder gleich 0 oder größer als die mit dem Zusatz LINE-COUNT der programmeinleitenden Anweisung bzw. NEW-PAGE definierten Seitenlänge in sy-linct ist, wird der Zusatz TO LINE ignoriert und stattdessen die Anweisung SKIP ohne Zusatz ausgeführt (siehe oben).



Hinweis

Wenn der Listen-Cursor mit SKIP TO LINE in die erste Listenzeile positioniert wird und die Liste einen Standardseitenkopf hat, werden die Ausgaben in die erste Zeile durch die Standardüberschrift überschrieben. Wenn mit SKIP TO LINE aber in die Zeilen von Seitenköpfen und Seitenfüßen positioniert wird, die zu TOP-OF-PAGE und END-OF-PAGE definiert wurden, werden die Seitenköpfe bzw. -füße überschrieben.



Beispiel

Die erste SKIP-Anweisung erzeugt beim Ereignis TOP-OF-PAGE eine Leerzeile. Die zweite SKIP-Anweisung positioniert den Listen-Cursor in dieser Zeile.

REPORT demo_skip NO STANDARD PAGE HEADING.

DATA sum TYPE i.

TOP-OF-PAGE.
SKIP.
ULINE.

START-OF-SELECTION.
DO 10 TIMES.
WRITE / sy-index.
sum = sum + sy-index.
ENDDO.

SKIP TO LINE 1.
WRITE: 'Numbers with sum' COLOR COL_HEADING,
sum COLOR COL_TOTAL.

Re: Felder vergleichen (E-Mails in einer Tabelle)

Wie bekommt man es hin dass beim vergleichen der E-Mail im Select Single keine Groß- und Kleinschreibung beachtet wird?

Re: Felder vergleichen (E-Mails in einer Tabelle)

Jetzt frage ich mich nur noch was das "SKIP." am Ende des Codes macht

Der SKIP ist nicht mehr und nicht weniger als eine schönere Variante Deines

WRITE /.

Wie meinst du das mit den Schlüsselfeldern? Also das mit der richtigen Reihenfolge macht Sinn, aber sollte man immer alle Schlüsselfelder benutzen? Also in der Tabelle adr6 auch "Datum gültig von" und "Laufende Nummer"?

Na ja, der Primärschlüssel der Tabelle ist ja insbesondere auch ein Index. Einen Index zu nutzen ist offensichtlich sinnvoll, da das System sonst sequentiell durch die gesamte Datenbank rasen und jeden einzelnen Eintrag anschauen muss.

Und an dieser Stelle ist die Reihenfolge der Felder durchaus relevant. Zwar nicht unbedingt die Reihenfolge, in der sie in Deinem Code stehen, denn wie gesagt, das sortiert sich der Datenbankoptimierer bei Bedarf selber um, aber bei der Frage, welche Indexfelder sich überhaupt abzugeben lohnt, macht es einen Unterschied.

Worauf man dabei achten muss, kann man sich ganz einfach merken und herleiten, wenn man sich im Geiste vorstellt, man würde Telefonnummern in einem Telefonbuch suchen. Solch Telefonbuch enthält Nachnamen, Vornamen und dazu gehörige Telefonnummern. Stell Dir vor, ich gebe Dir ein Telefonbuch und bitte Dich, die Nummer meines Kumpels Schlumiklaus zu suchen. Diesen schrägen Vornamen gibt es sicherlich nur einmal, und der Vorname ist ja auch ein Indexfeld, also sollte es doch ganz leicht sein, gelle?

Nix. Da das Telefonbuch nach Nachnamen und dann erst nach Vornamen sortiert ist, müsstest Du dennoch alle 1000 Seiten durchgehen und jede Zeile einzeln durchschauen, ob da jemand mit Vornamen Schlumiklaus heißt. Das von mir genannte Indexfeld nützt Dir also nichts.

Gebe ich Dir stattdessen nur den Nachnamen, nämlich "Schmidt", dann bist Du schon ein ganzes Stück weiter, denn Du kannst das alphabetisch sortierte Buch direkt beim Buchstaben S aufschlagen, dann nach dem Abschnitt Sc suchen usw. und wirst die Schmidts schnell finden.

Blöd nur, dass es 5 Seiten "Schmidt" im Telefonbuch gibt. Wenn ich jetzt nur weiß, dass ich den Schmidt im Waldweg 5 brauche, dann musst Du immerhin noch jene 5 Seiten durchackern. An dieser Stelle ist es jetzt aber hilfreich, wenn ich Dir auch noch sage, dass der Vorname Schlumiklaus lautet, denn die Schmidts sind ja unter sich nach Vornamen sortiert, und so wirst Du ihn schnell finden, ohne jeden einzelnen Schmidt anschauen zu müssen. Die Datenbank macht es ganz genauso!

Was lernen wir daraus? Die Angabe eines Schlüsselfeldes ist für die Suchoptimierung hilfreich, jedoch nur, wenn Du auch alle davorliegenden Schlüsselfelder angegeben hast, und zwar auf Gleichheit! Wenn ich Dir sage, der Nachname ist ungleich Schneider, dann haste trotzdem nix gekonnt und musst das ganze Telefonbuch nach Schlumiklaus durchsuchen.

Eine Sonderstellung nimmt dabei größer/kleiner ein. Wenn ich Dir sage, der Nachname ist (im Alphabet) größer als Meier, dann hast Du zwar trotzdem noch viel vor Dir, aber immerhin kannst Du die erste Hälfte des Telefonbuches weglassen. Damit hast Du schon viel gewonnen. Der Vorname nützt Dir dann allerdings nichts: Du musst dann ab Meier trotzdem jede einzelne Zeile durchsuchen, bis Du Schlumiklaus gefunden hast. Der Datenbank geht es genauso.

Was lernen wir daraus? Eine größer/kleiner-Angabe ist dann und nur dann für die Suchoptimierung hilfreich, wenn alle im Schlüssel davorliegenden Felder mit Gleichheit angegeben wurden. Schlüsselfelder, die nach dem auf grö0er/kleiner geprüften Feld kommen, bringen für die Suchoptimierung nichts mehr. (Genauso ist es auch bei einem LOOP WHERE auf eine interne Tabelle des Typ SORTED.)

Wahrscheinlich ist das auch der Grund, weshalb in der PA0001 das Feld ENDDA vor dem Feld BEGDA kommt, obwohl sich das komisch liest. Meist wird man den Datensatz für einen bestimmten Tag haben wollen, also mit BEGDA <= SY-DATUM AND ENDDA >= SY-DATUM suchen. Aber in der Zukunft wird es für diese Personalnummer nicht viele Sätze geben, wohl aber (möglicherweise) in der Vergangenheit, so dass ENDDA >= SY-DATUM schon eine viel genauere Angabe ist als BEGDA <= SY-DATUM. Da wegen des größer/kleiner nur eins von beiden für die Suchoptimierung genutzt werden kann, war es pfiffig von der SAP, das Feld ENDDA zuerst in den Index zu schreiben, da dessen Einschränkung viel weniger einzeln zu durchsuchende Werte übrig lässt.

Damit dürfte klar werden, weshalb es wichtig ist, sich auch bei der Definition einer eigenen Datenbanktabelle nicht nur zu überlegen, welche Felder in den Schlüssel gehören, sondern auch, in welcher Reihenfolge man sie dort aufnehmen sollte. Die Felder, die bei einer Suche am wahrscheinlichsten bekannt sein werden (Kundennummer, Materialnummer, Personalnummer, Belegnummer, ...) gehören an den Anfang. Ganz am Ende des Schlüssels sollten dann Verlegenheitsfelder wie die "Laufende Nummer" in der ADR6 sein, die nur deshalb da sind, weil man die Chance haben möchte, mehrere Tabellenzeilen mit ansonsten identischem Schlüssel einzufügen. Natürlich sollte man seine Tabellen nach Möglichkeit so designen, dass man solche Verlegenheitszählfelder gar nicht braucht.

Wenn man dennoch zuweilen auch über ganz andere Felder suchen muss, dann hat man die Möglichkeit, in der SE11 zusätzliche Datenbankindizes anzulegen. Dabei muss man aber im Hinterkopf behalten, dass die Datenbank bei jedem INSERT automatisch alle Indizes korrekt mitschreiben muss, so dass das Ganze mit jedem zusätzlich auf der Datenbank vorhandenem Index voluminöser und langsamer wird.

Wie bekommt man es hin dass beim vergleichen der E-Mail im Select Single keine Groß- und Kleinschreibung beachtet wird?

Ein weiterer Grund, zunächst einen SELECT INTO TABLE zu machen und dann per LOOP auf der internen Tabelle weiterzuarbeiten. Dann kannst Du diese nämlich rasch mit
einheitlich in Großbuchstaben wandeln und anschließend in der so auf Großbuchstaben normierten Tabelle suchen.

Geht nicht direkt mit den Standardbefehlen von ABAP, sondern das ist der typische Anwendungsfall bei dem man darüber nachdenken kann, ob man sich nicht mit EXEC SQL vertraut machen sollte.

Damit ist man aber schon dicht am Hack, denn die genaue Syntax von Native SQL kann sich je nach Datenbank unterscheiden. Bei uns wurde vor einiger Zeit Oracle durch Sybase ausgetauscht, weil wir als HANA-Nutzer Sybase kostenlos benutzen dürfen, wohingegen Oracle ja fürstliche Lizenzgebühren zu nehmen pflegt. Wenn Du dann solch Kram in Deinen Programmen hast... ne, da arbeite ich lieber konservativ mit internen Tabellen, die ich mir mit dem TRANSLATE-Befehl passend zurechtwandle.