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.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.
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.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.
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 PNPCEDeathAndPain hat geschrieben: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.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.
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.
Da hätte ich gerne mal die genauen Quellcodes Deiner Beispielprogramme gesehen.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.
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.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.
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.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.
Ja, und zwar dass ich Dir gesagt habe, dass Du nicht per LOOP aus einer logischen Datenbank lesen kannst.HansPeter hat geschrieben:Allerdings passiert bei Eingabe einer existierenden Personalnummer nichts beim ausführen des Programms.
Hab ich etwas vergessen?
Mein Betreuer hat folgendes Beipsielprogramm. Ehrlich gesagt finde ich keine guten Beispielprogramme, gibt es da eine Demo von der SAP?DeathAndPain hat geschrieben: Ja, und zwar dass ich Dir gesagt habe, dass Du nicht per LOOP aus einer logischen Datenbank lesen kannst.
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.
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.
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
DeathAndPain