Logische Datenbank: Selektieren mit Loop

Getting started ... Alles für einen gelungenen Start.
26 Beiträge • Vorherige Seite 2 von 2 (current)
26 Beiträge Vorherige Seite 2 von 2 (current)

Re: Logische Datenbank: Selektieren mit Loop

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
SaskuAc hat geschrieben:Und Sie sind, zu meinem erstaunen, auch sehr performant. Ob ich nun einen Select XXXXXX, YYYYYYY, from pa0001 mache oder die pnpce ( die neue version der pnp ) verwende, macht keinen unterschied. insbesondere wegen der berechtigungsprüfung auf die direkte Person ist dort performanter als wenn ich ein "authority-check" mache.
Ich weiß ja nicht, was Du da machst, aber alle LDB-basierten Programme, die ich bisher gesehen habe (und ich rede vom HCM), waren quälend langsam. Habe gerade erst einen großen Report, der die Daten aller Mitarbeiter ausgibt, von LDB auf händische Programmierung umgestellt. Die Laufzeit sank auf einen Bruchteil! Bei händischer Programmierung kannst Du dann sogar noch Daten effizient in internen Tabellen puffern, die Du mit Feinheiten wie FOR ALL ENTRIES IN füllst. Dadurch hast Du pro Infotyp nur einen einzigen Datenbankzugriff.

Das sind Größenordnungen, was ich auf diese Weise an Laufzeit herausgeholt habe.

Kopie aus einer Seite von Andreas Unkelbach
wreichelt hat geschrieben:Logische Datenbanken
enthalten schon Verknüpfungen und können direkt als Grundlage für ein Infoset verwendet werden. Dieses hat den Vorteil, dass man nicht selbst erst einzelne Tabellenverknüpfungen erstellen muss.
Das ist richtig und entspricht auch dem, was ich gesagt habe: Für Queries sind LDB eine gute Sache, weil man sich damit auf die Schnelle alle möglichen Auswertungen zusammenklicken kann. Infosets dienen ja nur dem Zweck, in Queries verwendet zu werden.

Das entkräftet aber nicht Ralfs Einwände, denn dass man LDBs als Grundlage von Infosets verwenden kann, rechtfertigt nicht, diese trägen Gebilde mit ihrem eigenwilligen Selektionsbildschirm, der auch nicht für jedes Programm taugt, in eigenen, händisch programmierten Reports zu verwenden. Ich finde es noch nicht mal nennenswert schneller oder übersichtlicher zu programmieren, wenn man eine LDB anstelle eines direkten SELECT auf die entsprechende PA-Tabelle macht. Berechtigungsprüfung ok, aber da langt ein Aufruf des entsprechenden Funktionsbausteins, um die auch bei händischer Programmierung zu integrieren. Bleibt trotzdem drastisch schneller.

Nicht ohne Grund werden bei der Programmierung mit LDBs auch noch Makros verwendet. wreichelt hat in seinem Code ein Beispiel genannt: RP-SEL-EIN-AUS-INIT Ein schönes Schätzchen aus der TRMAC, also vom Programmierdesign her vom allerfeinsten. :D

Nene, LDBs sind mir in eigenen Programmen nix.

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Logische Datenbank: Selektieren mit Loop

Beitrag von SaskuAc (Specialist / 321 / 37 / 43 ) »
DeathAndPain hat geschrieben:
SaskuAc hat geschrieben:Und Sie sind, zu meinem erstaunen, auch sehr performant. Ob ich nun einen Select XXXXXX, YYYYYYY, from pa0001 mache oder die pnpce ( die neue version der pnp ) verwende, macht keinen unterschied. insbesondere wegen der berechtigungsprüfung auf die direkte Person ist dort performanter als wenn ich ein "authority-check" mache.
Ich weiß ja nicht, was Du da machst, aber alle LDB-basierten Programme, die ich bisher gesehen habe (und ich rede vom HCM), waren quälend langsam. Habe gerade erst einen großen Report, der die Daten aller Mitarbeiter ausgibt, von LDB auf händische Programmierung umgestellt. Die Laufzeit sank auf einen Bruchteil! Bei händischer Programmierung kannst Du dann sogar noch Daten effizient in internen Tabellen puffern, die Du mit Feinheiten wie FOR ALL ENTRIES IN füllst. Dadurch hast Du pro Infotyp nur einen einzigen Datenbankzugriff.
Also ich habe jetzt einfach nur mal beispielsweise auf unserem Dev-System alle aktiven Mitarbeiter ( heißt infotyp 0000-stat2 eq '3' ) per Select und anschließendem Authority Check geprüft, und per PNPCE
meine Messung mit der Klasse cl_abap_runtime ergab, dass die LDB knapp um ein viertel schneller ist. - Dort ist dann ( im normalfall ) die Berechtigungsprüfung wesentlich sicherer ( zumindest wenn man im Standard bleibt und keine eigenen dazu prüfen möchte ) - ein standard selektionsbild wurde aufgebaut, welches man den Personalern nicht immer wieder neu erklären muss ( und es ist gleichzeitig auch sehr stark, was die selektion betrifft, man muss keine wirklichen einbußen machen )
Ein Vorteil von LDBs sind auch noch, dass eigentlich jeder Entwickler weiß ( in den jeweiligen Modulen ) wie mit den einzelnen sachen gearbeitet werden soll und wie sie funktionieren. Häufig ist es mit selects so, dass man sie nicht wirklich lesen kann.

Möchte hier natürlich darauf hinweisen, dass ich nur von der PNPCE spreche - die anderen LDBs kenne ich nicht so wirklich und habe mit denen noch nicht gearbeitet.

Natürlich weiß ich auch, dass LDBs nicht das große Ding sind und auch ziemlich veraltet. Aber wenn ich jetzt einen Report schreibe, welcher die BEM ( BerufsEingliederungsMaßnahmen ) berechnen und einladen soll, kann ich das schlecht mit einem Query machen. Da brauche ich nunmal einen Report, weil dort noch Logik und Versand dahinter steckt. Und in diesem Report ist es wesentlich effektiver und einfacher mit der LDB zu programmieren als mit verschiedenen Selects und eventuell vergessenen berechtigungsprüfungen.

Re: Logische Datenbank: Selektieren mit Loop

Beitrag von HansPeter (ForumUser / 13 / 0 / 0 ) »
Habe jetzt folgendes:
Allerdings passiert bei Eingabe einer existierenden Personalnummer nichts beim ausführen des Programms.
Hab ich etwas vergessen? Mit einer internen Tabelle muss ich doch nicht arbeiten, weil p0001 und p0002 eine Kopfzeile besitzen, oder.

Code: Alles auswählen.

REPORT zyr_test_logidb.

TABLES pernr.

INFOTYPES: 0001,
           0002.

*DATA it_tab TYPE TABLE OF pernr.



START-OF-SELECTION.

  "  GET pernr liefert jedes mal eine Personalnummer und füllt die Infotypen
  "  get pernr füllt außerdem die in infotypes angegebenen infotyp tabellen p0001, p0002 -  Tabellen mit Kopzeile

GET pernr.
  PERFORM get_pernr.

*&---------------------------------------------------------------------*
*&      Form  GET_PERNR
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*  -->  p1        text
*  <--  p2        text
*----------------------------------------------------------------------*
FORM get_pernr.

  LOOP AT p0001
    WHERE persg = '1' AND persk = '01'.
    WRITE: /    p0001-persg,
                p0001-persk.
  ENDLOOP.

  LOOP AT p0002.
    WRITE: /    p0002-nachn,
                p0002-vorna,
                p0002-gbdat.
  ENDLOOP.
  SORT BY p0002-gbdat DESCENDING.
ENDFORM.

END-OF-SELECTION.

Re: Logische Datenbank: Selektieren mit Loop

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Also ich habe jetzt einfach nur mal beispielsweise auf unserem Dev-System alle aktiven Mitarbeiter ( heißt infotyp 0000-stat2 eq '3' ) per Select und anschließendem Authority Check geprüft, und per PNPCE
meine Messung mit der Klasse cl_abap_runtime ergab, dass die LDB knapp um ein viertel schneller ist.
Da hätte ich gerne mal die genauen Quellcodes Deiner Beispielprogramme gesehen.
Ein Vorteil von LDBs sind auch noch, dass eigentlich jeder Entwickler weiß ( in den jeweiligen Modulen ) wie mit den einzelnen sachen gearbeitet werden soll und wie sie funktionieren. Häufig ist es mit selects so, dass man sie nicht wirklich lesen kann.
Ehrlich gesagt sehe ich das genau umgekehrt: Bei der LDB kommen die Daten irgendwie aus einer nicht wirklich debuggbaren Black Box. Es gibt zwei Zeitraumsauswahlranges, die miteinander verzahnt sind und einem da Streiche spielen können. Da komme ich schon mal ins Grübeln, warum die LDB jetzt genau diese Werte geliefert hat. Über einen SELECT hingegen kann man nicht diskutieren: Da sieht man genau, mit welchen Kriterien aus der Datenbank gelesen wird und kann bei Bedarf auch einen Breakpoint drauf setzen, um sich die genauen Parameter des SELECTs anzuschauen.

Und ganz ehrlich: Wer einen SELECT nicht sauber interpretieren kann, ist nach meiner Überzeugung entweder in dem betreffenden Modul nicht richtig zu Hause oder hat keine Ahnung von ABAP bzw. SQL.
Natürlich weiß ich auch, dass LDBs nicht das große Ding sind und auch ziemlich veraltet. Aber wenn ich jetzt einen Report schreibe, welcher die BEM ( BerufsEingliederungsMaßnahmen ) berechnen und einladen soll, kann ich das schlecht mit einem Query machen. Da brauche ich nunmal einen Report, weil dort noch Logik und Versand dahinter steckt. Und in diesem Report ist es wesentlich effektiver und einfacher mit der LDB zu programmieren als mit verschiedenen Selects und eventuell vergessenen berechtigungsprüfungen.
Ich bin ganz Deiner Meinung, dass man für bestimmte Zwecke eigene Reports braucht. Nicht zustimmen tue ich Dir bei der Formulierung "effektiver und einfacher mit der LDB". Und was die Berechtigungsprüfungen angeht: Einerseits braucht man die in vielen Fällen nicht oder will sie sogar gezielt nicht haben und andererseits bedeuten händisch durchgeführte Berechtigungsprüfungen (die, wie gesagt, nur aus einem einfachen CALL FUNCTION bestehen), dass man auf fehlende Berechtigungen sinnvoll reagieren kann, beispielsweise mit Fehler- oder Hinweismeldungen. Bei LDBs bekommst Du einfach weniger Suchergebnisse. Du weißt nicht, ob Dir was fehlt oder nicht. Bei Queries bekommst Du nach meiner Erinnerung eine ominöse Meldung, dass die Ergebnisliste nicht vollständig sei, aber was fehlt und warum und ob das für den jeweiligen Auswertungszweck relevant ist, kann man nur raten. Da habe ich schon einige Supportanfragen von Anwendern wegen gehabt. Bei eigenen Reports kannst Du darauf so detailliert wie im jeweiligen Fall geboten reagieren und z.B. sagen: "Der IT 8 dieses Mitarbeiters wurde nicht dargestellt, da Sie darauf nicht berechtigt sind." Die restlichen Werte für den Mitarbeiter sind dann aber trotzdem da, und der Sachbearbeiter weiß, welche Informationen ihm vorenthalten werden und hat auch eine Vorstellung warum.

Re: Logische Datenbank: Selektieren mit Loop

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
HansPeter hat geschrieben:Allerdings passiert bei Eingabe einer existierenden Personalnummer nichts beim ausführen des Programms.
Hab ich etwas vergessen?
Ja, und zwar dass ich Dir gesagt habe, dass Du nicht per LOOP aus einer logischen Datenbank lesen kannst.

Der GET-Befehl selber spannt die Schleife auf. Oder genauer gesagt, die Schleife läuft zwischen START-OF-SELECTION und END-OF-SELECTION. Jeder GET liefert Dir eine Ergebniszeile. Es ist auch nicht üblich, da einen PERFORM-Absprung reinzupacken. Der START-OF-SELECTION selbst ist der kapselnde Verarbeitungsblock - jedenfalls hinsichtlich der ältlichen Programmierstruktur, mit der bei LDB gearbeitet wird.

Deswegen gibt es den END-OF-SELECTION auch nur in Programmen, die mit LDB arbeiten. (Man kann ihn auch in anderen Programmen verwenden, aber dort bewirkt er nichts und steht nur aus Kosmetik da.)

Wie gesagt, lies Dir mal durch, wie man auf LDB zugreift, oder schau Dir funktionierende Beispielprogramme an.

Re: Logische Datenbank: Selektieren mit Loop

Beitrag von HansPeter (ForumUser / 13 / 0 / 0 ) »
DeathAndPain hat geschrieben: Ja, und zwar dass ich Dir gesagt habe, dass Du nicht per LOOP aus einer logischen Datenbank lesen kannst.
Mein Betreuer hat folgendes Beipsielprogramm. Ehrlich gesagt finde ich keine guten Beispielprogramme, gibt es da eine Demo von der SAP?
Der Tutor bei der SAP hat beim Seminar die Logischen Datenbanken komplett ausgelassen mit dem Kommentar "Die nutzt man heute sowieso nicht mehr".

Code: Alles auswählen.

[/REPORT  ZYR_TEST_PNP.

tables: pernr.        "Standard Selektionen für HR-Stammdaten-Reporting

infotypes: 0000,      "Massnahmen
           0001,      "Org. Zuordnung
           0002,      "Daten zur Person
           0008.



get pernr.
  perform get_pernr.                      "IT lesen und ausgeben

end-of-SELECTION.

*&---------------------------------------------------------------------*
*&      Form  GET_PERNR
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*  -->  p1        text
*  <--  p2        text
*----------------------------------------------------------------------*
form GET_PERNR .

   loop at p0000.
     write: /001 p0000-pernr,
                 p0000-INFTY,
                 p0000-SUBTY,
                 p0000-BEGDA,
                 p0000-endda.
   endloop.
   loop at p0001.
     write: /001 p0001-pernr,
                 p0001-INFTY,
                 p0001-SUBTY,
                 p0001-BEGDA,
                 p0001-endda.
   endloop.
   loop at p0002.
     write: /001 p0002-pernr,
                 p0002-INFTY,
                 p0002-SUBTY,
                 p0002-BEGDA,
                 p0002-endda.
   endloop.
endform.  

Re: Logische Datenbank: Selektieren mit Loop

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Dein Tutor hat recht. Dein Betreuer scheint keine Ahnung zu haben, wovon er redet, wenn er solch funktionsuntüchtiges Beispielprogramm bietet.

Wenn Du für Deinen Betreuer trotzdem sowas schreiben möchtest, dann sollst Du hier in Gottes Namen ein kleines Beispielprogramm haben:

Code: Alles auswählen.

*&---------------------------------------------------------------------*
*& Report ZTEST6
*&---------------------------------------------------------------------*
REPORT ZTEST6.

TABLES PERNR.      "Standard Selektionen für HR-Stammdaten-Reporting

INFOTYPES: 0000,
           0001,
           0002,
           0016.

START-OF-SELECTION.

  GET PERNR.

  RP-PROVIDE-FROM-LAST P0000 SPACE PN-BEGDA PN-BEGDA.
  RP-PROVIDE-FROM-LAST P0001 SPACE PN-BEGDA PN-BEGDA.
  RP-PROVIDE-FROM-LAST P0002 SPACE PN-BEGDA PN-BEGDA.
  RP-PROVIDE-FROM-LAST P0016 SPACE PN-BEGDA PN-BEGDA.

  WRITE: / P0001-PERNR, P0001-ENAME.

END-OF-SELECTION.
Achte darauf, dass Du in den Programmeigenschaften in der SE38 die logische Datenbank PNP einträgst. Dann kannst Du es direkt wie oben abgebildet kompilieren und ausführen.

Zu Demozwecken gebe ich in dem WRITE nur die Personalnummer und den vollständigen Namen der gefundenen Mitarbeiter aus. Dir stünden aber alle Feldwerte der Infotypen 0, 1, 2 und 16 zur Verfügung. Wie Du bei Bedarf noch andere Infotypen ergänzen kannst, dürfte offensichtlich sein.

@SaskuAc: Hier wird auch klar, dass die logische Datenbank immer SELECT * macht und damit ohne Ende nicht benötigte Spalten liest. Ein Grund mehr, weshalb sie langsam ist.
Zuletzt geändert von DeathAndPain am 22.01.2019 10:12, insgesamt 1-mal geändert.

Re: Logische Datenbank: Selektieren mit Loop

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
DeathAndPain


Re: Logische Datenbank: Selektieren mit Loop

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Danke, netter Link. Am besten gefällt mir daran freilich die Überschrift:

Bild

Damit dürfte jeder Zweifel beseitigt sein, was die SAP von Logischen Datenbanken hält.

Re: Logische Datenbank: Selektieren mit Loop

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Ich wollte mir den Hinweis auf "obsolet" verkneifen, weil man sich hier damit keine Freunde macht.....

Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Logische Datenbank: Selektieren mit Loop

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Als wenn dich das je interessiert hätte :)
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Vergleichbare Themen

0
Antw.
922
Views
Logische Datenbank - Wurzelknoten
von littleJohn » 26.05.2008 15:55 • Verfasst in ABAP® Core
3
Antw.
1847
Views
Logische Datenbank|Sel-option|
von Bajdu » 08.08.2006 15:09 • Verfasst in ABAP® Core
6
Antw.
3788
Views
Logische Datenbank / Select Options
von Prego » 28.06.2007 08:59 • Verfasst in ABAP® Core
0
Antw.
1105
Views
Logische Datenbank ( GLG ) anpassen mit neuer Tabelle
von Kleenmex » 06.03.2007 09:00 • Verfasst in Financials
6
Antw.
3301
Views
Report für Logische Datenbank (Über mehrere Tabellen)
von franz-ho » 20.07.2015 14:48 • Verfasst in ABAP® für Anfänger

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140