spezielle select-abfrage

spezielle select-abfrage

hallo,

ich sollen ne abfrage schreiben bei der das Betragsfeld auf mehrer felder aufgetielt werden soll.

in der tabelle stehn im betragsfeld pos und neg beträge.

die pos beträge sollen in das itab-feld Forderungen und die neg beträge in das itab-feld verbindlichkeiten.

kann ich des ganze in ner select-schleife so definiern oder muß des ganze über nen loop passiern?

hab da nämlich keine ahung wie des gehn soll, aber ich glaub ihr könnt mir dabei helfen.

Hallo,

der Programmierer von heute benutzt eigentlich keine SELECT-Schleifen mehr

ja, das ist leider nur zu wahr.

Deshalb läuft die Tabelle SNAP täglich über mit Kurzdumps wg. Speicherproblemen in Zusammenhang mit internen Tabellen (gleichmäßig verteilt auf Standard- und kundeneigene Programme).

Deshalb steht der 'Programmierer von heute' vor unlösbaren Problemen, wenn er mal 'ne DB-Tabelle lesen muß, die nicht in eine interne Tabelle paßt.

Deshalb muß die Hardware mit Unmengen von Speicher aufgerüstet werden, damit überhaupt noch was läuft.

So, das mußte mal gesagt werden...

MfG Jürgen

Hallo Ralf,

Du findest es besser die DB mit Anfragen nach Einzelsätzen zuzutackern?

Nein.

Es gibt es nur zwei Möglichkeiten, Einzelsätze aus der Datenbank zu lesen: SELECT SINGLE mit vollqualifiziertem Schlüssel oder ein SELECT...ENDSELECT, der aufgrund der WHERE-Bedingung nur einen Ergebnissatz liefert.

Ansonsten macht die Datenbank auch beim SELECT...ENDSELECT einen Array Fetch, d.h. es werden immer soviel Datensätze auf einmal gelesen, wie in den (datenbankabhängigen) Puffer passen; das können bei einer knappen Feldliste einige Tausend Sätze sein, wie man beim SQL-Trace sehen kann.

Die Wirkung ist ähnlich wie bei FOR ALL ENTRIES, wobei die Sätze aus der ITAB blockweise gelesen werden.

Im übrigen geht auf der Datenbank auch nicht mehr viel, wenn sich jemand die BSEG mit SELECT INTO TABLE reinzieht.

Der (relativ geringe) Performance-Gewinn des einzelnen Reports geht zum einen auf Kosten der Gesamtperformance des Systems und wird zum anderen in der Regel durch endlose LOOPs über die interne(n) Tabelle(n) wieder verspielt.

Programme mit konsequentem SELECT INTO TABLE haben den schweren Geburtsfehler, daß sie prinzipiell immer zum Kurzdump führen, wenn nur die Datenbasis genügend groß und/oder die Selektionen genügend weit sind.

Ein gutes Programm zeichnet sich aber nicht nur durch gute Performance aus, es sollte darüber hinaus auch kooperativ und skalierbar sein. Die beiden letzten Kriterien sind bei Programmen mit SELECT INTO TABLE in der Regel nicht erfüllt.

MfG Jürgen

JDO hat geschrieben:Ein gutes Programm zeichnet sich aber nicht nur durch gute Performance aus, es sollte darüber hinaus auch kooperativ und skalierbar sein. Die beiden letzten Kriterien sind bei Programmen mit SELECT INTO TABLE in der Regel nicht erfüllt.

Hi Jürgen!
was wären denn Ansätze, um ein Programm "kooperativ und skalierbar" zu machen? Select into table hat natürlich in der Tat Probleme bei riesigen Datenmengen. Aber ein SELECT-ENDSELECT ist dabei meines Erachtens auch nicht die Lösung, sondern ein Blockweises Lesen der Datensätze in eine interne Tabelle. Das mache ich aber nur in Notfällen, weil ich es als sehr aufwändig empfinde. Zudem bin ich mir da auch nicht sicher, welche Methode zum Blockweisen lesen die richtige wäre...
Mach doch mal ein paar Vorschläge, bitte!

BlackMail hat geschrieben:

JDO hat geschrieben: Deshalb muß die Hardware mit Unmengen von Speicher aufgerüstet werden, damit überhaupt noch was läuft.

Es gibt ja auch noch den Befehl SELECT ... INTO TABLE ... PACKAGE SIZE ...

Gruß BlackMail.

Oh, das hat ewx ja schon geschrieben:

ewx hat geschrieben: Aber ein SELECT-ENDSELECT ist dabei meines Erachtens auch nicht die Lösung, sondern ein Blockweises Lesen der Datensätze in eine interne Tabelle.

NACHTRAG:

Aber um auch nochmal konstruktiv zu sein: Bei SELECT-Schleifen, stößt man auch auf das Problem, dass sich die Programme schlecht debuggen lassen, weil ein COMMIT bei offenem DB-Cursor zum Dump führt.

JDO hat natürlich Recht und das haben ja auch alle schon bestätigt, dass man vernünftig mit dem SELECT ... INTO TABLE umgehen muss. Man liest ja nicht immer eine komplette Tabelle in den Speicher. Und wenn man tatsächlich einmal mehr Daten lesen muss, liegt es in der Verantwortung des Programmierers, den Speicher so schnell wie möglich wieder freizugeben.

Der Speicherbedarf sollte auch dadurch in Grenzen gehalten werden, dass nur die relevanten Felder gelesen werden. Ich habe häufig gesehen, dass mit SELECT * Daten gelesen wurden obwohl das nicht notwendig war. Es ist natürlich auch einfacher, eine interne Tabelle mit Bezug aufs DDIC zu erstellen, als sich selbst eine neue DDIC-Struktur (oder einen programminternen Strukturtyp) mit den relevanten Feldern zu definieren.

Vielleicht hat JDO aber ja tatsächlich noch Tipps, da er sich ja scheinbar gut mit der DB-Kommunikation auskennt.

Gruß BlackMail.