ich möchte einen export der Belege und Positionen über Jahre hinweg (>1Mio Datensätze) machen und zwar strukturiert

Belegkopf + X Belege

Belegkopf + Y Belege

...

Dazu habe ich mir einen Struktur angelegt, welche die BKPF enthält und eine Tabelle von BSID bzw BSAD. So weit so gut.

Nun zur Selektion und dem Zusammenführen.

Was würdet ihr empfehlen?

A) Die Views BKPF_BSID und BKPF_BSAD und das ganze dann strukturieren?

B) BKPF ziehen und dann die Positionen in einzelnen Selects?

C) BKPF ziehen und BSID/BSAD ziehen und dann peer BKPF-Loop mit innerem BSID/BSAD-Loop zusammenführen?

D) BKPF ziehen und BSID/BSAD ziehen und sortieren und frech read table mit binary search, die Zeile löschen und die nächste mit binary search usw.

E) ganz was anderes machen?

Ich mache aktuell C) aber das zusammenführen dauert erschreckend lange, daher bin ich auf die "grandiose" Idee mit D) gekommen.

Vielen Dank

Martin

warum BSID und BSAD ? BSID enthält doch alle Debitorenbelege, sowohl ausgeglichen und auch offen.

Warum alle Belege ziehen ? wohin geht die Reise mit den Daten ?

Gruß Wolfgang

BSID enthält auch die ausgeglichenen?

Ich erzeuge aus den Daten eine XML für ein anderes Tool als Initialexport und dann nur noch die täglichen, was dann wiederum kein Problem ist.

Viele Grüße

Martin

BSAD enthält alle Debitorenpodten. BSID war ein Fehler.

Offene debitorische Posten stehen in der Tabelle BSID. Wenn ein Beleg ausgeziffert wird, z.B. durch Buchung einer entsprechenden Zahlung oder einer sonstigen Ausgleichsbuchung, wandert der Posten von der Tabelle BSID in die BSAD und erhält eine Ausgleichsbelegnummer (Feld BSAD-AUGBL) sowie ein Ausgleichsdatum (BSAD-AUGDT).

Gruß Wolfgang

wie Wolfgang schon unter #2 schrieb, kommt es auch darauf an, "wohin geht die Reise mit den Daten" (also ob diese beispielsweise "BKPF-weise" in eine sequentielle Datei geschrieben oder in eine Datenbanktabelle kopiert werden sollen).

Das Lesen selbst mit Variante C) ist schon ok, aber ich würde zur Beschleunigung mal als Alternative zum inneren Loop einen Array-Fetch probieren (select ... into table ...).

Freundliche Grüße - LaMancha

hallo Wolfgang,

danke an euch beide.

die Positions-Selects (wenn ich dich richtig verstehe) für die X-tausend Belegköpfe wollte ich mir eigentlich verkneifen. Lieber zwei "ordentliche" Selects und das ganze dann effizient im Code, wobei das mit dem effizient grad nicht so klappte.

Lösung C) bedeutet eben X-tausend loops mal X-tausend loops.

Aber ich hab vorhin nochmal mit nem Kollegen geredet und er meinte ich könnte auch über die Positionen loopen und per read table ... binary search den Kopf und dann die Position an den Kopf dranhängen. Die Köpfe sind ja eindeutig, daher passt das.

Ich wollte es mit Lösung D) anders herum machen und die benutzten positionen wegimprovisieren, was natürlich nicht unbedingt beste Programmierung ist.

VG

Martin

mein Vorschlag war, anstelle des inneren Loops einen Array-Fetch zu probieren. Dann würden eben nur X-tausend loops mal 1 Array-Fetch den Lesevorgang insgesamt wahrscheinlich beschleunigen.

Freundliche Grüße - LaMancha

warum nicht die BSID und BSAD in eine Tabelle, darüber dann den LOOP und den Belegkopf mittels SELECT SINGLE dazu lesen?

Damit würde der verschachtelte Loop entfallen.

Gruß Wolfgang

das hatte ich verstanden, aber wissentlich x-tausend Einzel-Datenbankzugriffe vermeide ich im allgemeinen.

Der verschachtelte/innere loop entfällt jetzt sowieso, da ich BSID und BSAD wie du beschreibst bereits in eine Tabelle packe, aber eben statt der Datenbankzugriffe das read table... binary search zu verwenden plane.

Da die Datenmengen um das ordentlich einer Laufzeitanalyse zu unterziehen dummerweise erst auf dem Q-System zu finden sind, kann ich leider nur schwer testen, ob es schneller ist die BKPF zu lesen und dann read table oder die BKPF einzeln zu selektieren.

Ich persönlich würde auf das read table tippen muss ich gestehen.

VG

Martin

ich bin nicht sicher, dass wir nicht aneinander vorbei reden.

Der Lesevorgang der Daten ist schnell. Ich habe eine Ladung Belegköpfe und eine Ladung Belegpositionen innerhalb von Sekunden. Ich hab also alles was ich benötige, nur noch nicht strukturiert.

Was eben lange dauert, ist aktuell das Anhängen der Belegpositionen an meine Belegköpfe mittels 2 Loops.

Auch wenn es von der Logik her einfacher sein mag, bin ich bezüglich der Laufzeit abgeneigt mehrere tausend Datenbankzugriffe durchzuführen, selbst wenn ich die Indizes nutze.

Aber wie gesagt, da bin will ich mich nicht 100%ig festlegen, dass das wirklich langsamer ist. Ist eher Bauchgefühl aus meinen bisherigen Erfahrungen.

Wie gesagt der Vorschlag meines Kollegen, die BSID/BSAD als Loop zu verwenden und dann die BKPF per read table...binary search ermitteln und die BSID/BSAD da dran zu hängen, war auch genau das was ich irgendwie im Kopf hatte, nur verkehrt herum.

Ich werde bei Gelegenheit mal beides ausprobieren und eine Laufzeitanalyse machen.

Wenn das Problem in der speicher-internen Verarbeitung (also nach dem Lesen aus der Datenbank) liegt: ist dann das Zusammenführen von Kopf- und Positionsdaten oder deren Schreiben in die weiterzuverarbeitenden Ziele das Zeitraubendere?

Viel Erfolg beim Ausprobieren - es sollte schon einen Weg geben, die Daten in angemessener Zeit in eine XML-Datei zu bringen (ca. 1 Mio. Datensätze sind für ein ausgewachsenes SAP-System eigentlich kein Problem).

ja das zusammenführen ist langsam.

Danke, wird schon schief gehen ^^

Wo die beiden loops Minuten brauchen, ist das innerhalb von praktisch nix fertig.

Klappt also sehr gut.