Standardtabellen vs andere Tabellen, Inline-Deklaration beim SELECT usw.

Alles rund um die Sprache ABAPÂź: Funktionsbausteine, Listen, ALV
6 BeitrĂ€ge • Seite 1 von 1
6 BeitrÀge Seite 1 von 1

Standardtabellen vs andere Tabellen, Inline-Deklaration beim SELECT usw.

Beitrag von DeathAndPain (Top Expert / 1438 / 156 / 330 ) » 28.09.2020 18:37
Hallo zusammen,

in einer PN hatte black_adept angeregt, dass ich zu folgendem Thema ein Fass eine Diskussion aufmache. 😊
black_adept hat geschrieben:
DeathAndPain hat geschrieben:Eigentlich ist mir ein SELECT INTO TABLE @DATA deshalb unsympathisch, weil man damit nur Standardtabellen erzeugen kann. Im Regelfall will man mit den Daten aber weiterarbeiten und braucht daher eine suchoptimierte Fassung.
Einfach weil das ein sehr interessantes Thema ist und ich z.B. allein wegen deines Worte "Regelfall" und anderer Posts von dir ganz anderer Meinung bin. Andererseits hat mich das mit der Inlinedeklaration auch schon gestört, wobei ich bei einem SELECT .. INTO TABLE @DATA( ) bei Bedarf halt mit READ BINARY SEARCH weitergemacht habe wenn benötigt so wie in alten Zeiten.
Aber eine Grundsatzdiskussion bzw. besser einen eigenen Thread mit einer Grundsatzdiskussion wĂ€re schon nett in diesem Forum. Zumal dann auch Unterthemen wie Tabellen mit mehrfachen SchlĂŒsseln und evtl. das Zeitverhalten bei diesen beim Aufbau der Tabellen behandelt werden könnte oder ab welcher TabellengrĂ¶ĂŸe sich sortierte Tabellen ĂŒberhaupt lohnen etc.
Ich steige einfach mal zu dem Thema ein.

Mir ist bewusst, dass sortierte Tabellen bzw. Hashtabellen sich performanceseitig erst ab einer bestimmten Zeilenzahl lohnen. Ich strebe sie aber immer an, selbst wenn meine interne Tabelle voraussichtlich nur 5 Zeilen enthalten wird, denn eine Tabelle strukturiert mit einem ordentlichen SchlĂŒssel zu deklarieren, sortiert nicht nur die eigenen Gedanken (was sich positiv auf die CodequalitĂ€t auswirkt), sondern macht es anderen auch leichter zu verstehen, welche Informationen sich in der Tabelle befinden und warum. Auch im Debugger ist ein sortierter Tabelleninhalt leichter lesbar. Eine 5-Zeilen-Tabelle zu sortieren oder zu hashen mag performancetechnisch nichts bringen, ist auf der anderen Seite aber auch kein Performance Hit, wenn man sie durchfĂŒhrt. Und gerade eine Hashtabelle ist eine Aussage in sich, was ihren Zweck und Verwendungsweise angeht.

Etwas anderes ist es allenfalls bei einem Fall wie der Knobelaufgabe (aus deren Thread mein obenstehendes Zitat stammt), wenn nĂ€mlich die in die interne Tabelle gelesenen Daten genau ein einziges Mal gebraucht werden und die Tabelle anschließend weg kann. Dann wĂ€re eine Sortierung in der Tat BeschĂ€ftigungstherapie und bringt auch performancetechnisch keine Vorteile.

Was mir freilich nicht gefĂ€llt, ist black_adepts obenstehender Vorschlag, auf den alten READ TABLE ... BINARY SEARCH zurĂŒckzufallen, weil der SELECT mit Inline-Deklaration nur Standardtabellen hergibt. Solch READ TABLE liest sich deutlich sperriger als eine Ă€quivalente 7.40-Notation, und dann muss man vorher ja auch noch einen expliziten SORT auf die Tabelle machen (oder diese Arbeit per ORDER BY der Datenbank aufhalsen). Zudem braucht man dafĂŒr die "neue" SELECT-Syntax mit den ganzen unĂŒbersichtlichen Escapesymbolen, die ich fĂŒr einen SchildbĂŒrgerstreich der SAP halte. (Es mag SpezialfĂ€lle geben, bei denen ein SELECT mit moderner Syntax ohne Escape-Symbole nicht eindeutig wĂ€re, aber in der Masse der FĂ€lle sind diese @-Zeichen nichts als Tipparbeit, deren Lohn dennoch nicht bessere, sondern schlechtere Lesbarkeit ist. Wahrscheinlich soll das eine Konzession an Programmierer sein, die von anderen Programmiersprachen kommen und die OpenSQL-Optik von ABAP nicht gewohnt sind. DafĂŒr sprechen auch Änderungen wie die Kommapflicht zwischen gelesenen Feldern im SELECT.)

Schreibarbeit beim Code sollte man hingegen dort nicht meiden, wo sie tatsĂ€chlich der besseren CodeverstĂ€ndlichkeit dient. Dazu gehören in meinen Augen - neben Parametern statt Attributen (= globalen Variablen) beim Aufruf von Unterroutinen - ordentliche lokale Typdefinitionen fĂŒr interne Tabellen, anstatt diese einfach per TYPE Datenbanktabelle (oder LIKE Datenbanktabelle) zu deklarieren und dann entweder per SELECT * zu befĂŒllen oder von den 20 Spalten nur die tatsĂ€chlich benötigten drei zu fĂŒllen. Beim Lesen des Codes ist dann nicht klar, was der semantische Inhalt dieser internen Tabelle sein soll, und besonders schlimm ist es, wenn jemand anders solchen Code debuggen soll. Nichts ist schlimmer im Debugger als eine interne Tabelle (deren genaue Funktion man noch nicht verstanden hat und aus dem Code herleiten möchte) mit reichlich MĂŒllspalten, die fĂŒr den Code ĂŒberhaupt keine Bedeutung haben und nur da sind, weil der Programmierer zu faul gewesen ist, die Tabelle hĂ€ndisch und auf den Punkt zu typisieren und die tatsĂ€chlich benötigten Spalten im SELECT aufzuzĂ€hlen.

Bei solcher lokaler Typdefinition kann man dann auch einen passenden TabellenschlĂŒssel vergeben, wenn möglich UNIQUE. Ich vermag nicht zu sagen, wieviele ABAP Dumps wegen Verletzung solcher unique keys mich auf die harte Tour darauf aufmerksam gemacht haben, dass ich einen Denkfehler in meinem Code hatte, nicht weit genug gedacht habe (Möglichkeiten nicht gesehen, die ich im Code berĂŒcksichtigen sollte) - oder eine Inkonsistenz der Datenbankdaten vorlag, die zu beseitigen ratsam war. Zuweilen bin ich mir auch nicht zu schade, den ASSERT-Befehl zu nutzen, zum einen als Fingerzeig fĂŒr zukĂŒnftige Leser dieses Codes (zu denen ich in einigen Monaten oder gar Jahren auch selber gehören kann), zum anderen um meine logischen Überlegungen in Stein zu gießen, damit das System mir das in ĂŒberzeugender Form um die Ohren haut, wenn meine Codelogik einen Denkfehler enthĂ€lt.

Wenn man sich aber die MĂŒhe macht, die interne Zieltabelle fĂŒr den SELECT vorher sauber mit den benötigten Spalten und (mindestens) einem ordentlichen TabellenschlĂŒssel zu deklarieren, dann braucht man auch keine Inline-Deklaration beim SELECT mehr und muss hinterher auch nicht mit SORT und READ TABLE ... BINARY SEARCH herumhampeln, die die Lesbarkeit zusĂ€tzlich erschweren und zum Teil sogar die gesparte Tipparbeit wieder zunichte machen.

Die Diskussion ist eröffnet. Lasst das Gemetzel beginnen! 😄


Re: Standardtabellen vs andere Tabellen, Inline-Deklaration beim SELECT usw.

Beitrag von black_adept (Top Expert / 3421 / 66 / 664 ) » 29.09.2020 00:51
Moin D&P,
da ich dich ja zu diesem Post genötigt habe kommt auch von hier die erste Antwort.
DeathAndPain hat geschrieben:Eigentlich ist mir ein SELECT INTO TABLE @DATA deshalb unsympathisch, weil man damit nur Standardtabellen erzeugen kann. Im Regelfall will man mit den Daten aber weiterarbeiten und braucht daher eine suchoptimierte Fassung.
Mich stört tatsĂ€chlich das Wort "Regelfall" - aber nicht nur bei dir sondern auch bei SAP die mich zu hĂ€ufig darauf hinweisen, dass ich evtl. kein "ORDER BY" in meinem SELECT habe. Aber in meinen typischen Aufgaben kommt es eben dauernd vor, dass ich kurz eine kleine Customizingtabelle vorhalten muss wo sich ein SchlĂŒsselzugriff einfach nicht lohnt oder wo ich ein paar Zeilen einer Tabelle abloopen muss und es völlig unerheblich ist in welcher Reihenfolge ich das mache ( z.B. Summation, ZĂ€hlen, irgend einen Eintrag mit besonderen Eigenschaften finden wobei nur wichtig ist, ob solch einer dabei ist oder nicht ). Beispiel wĂ€re etwa zu einem Auftrag herauszufinden ob es mindestens eine Position gibt fĂŒr welche eine ATP-PrĂŒfung einen bestimmten RĂŒckgabewert ĂŒberschreitet.
ThreadĂŒberschrift hat geschrieben:Standardtabellen vs andere Tabellen
Der typische Anwendungsfall ist bei mir eigentlich folgends banales Szenario. Der Fachbereich kommt daher und verlangt:"Wir brauchen ein Programm welches uns eine Liste ausspuckt in der das und das zu sehen ist wobei wir nach folgenden Kriterien selektieren wollen. Und wenn wir schon dabei sind - folgende Zusatzinformationen hÀtten wir gerne auch noch, auch wenn die mit dem aktuellen Kontext nicht so viel zu tun haben - aber wir brauchen das halt ..."
Hier bin ich halt ( und das ist eben oft der Fall ) schon gezwungen eine Standardtabelle zu verwenden einfach damit mir der AusgabeALV beim Sortieren nicht wegdumpt. Auch der initiale SELECT des Workloads und das spĂ€tere Anreichern der Daten benötigt eigentlich keine Sortierung, da ĂŒblicherweise Sortierungen einfach dem ALV mit seiner Layoutverwaltung ĂŒberlassen wird.
FĂŒr fast alles andere verwende ich ĂŒblicherweise Hash- und Sorttabellen solange nicht irgendwelche Interfaceparameter mich zwingen etwas anderes zu nehmen.
DeathAndPain hat geschrieben:@Zeichen und Kommata zwischen SELECT-Feldern
Die vorher unsaubere Syntax ist einfach bereinigt worden. Es war nie einzusehen warum in Teilen der Select-Statements Listen ohne Trennzeichen und in anderen Teilen Listen mit Trennzeichen verwendet wurden und ja - der Spezialfall wo das @-Zeichen ( etwa data: col type i, Update dtab set col = col + 1 vs. Update dtab set col = @col + 1 ) scheint vielen Leuten nicht gelÀufig oder wird halt nicht so hÀufig verwendet.
@Ralf: Hier ist eine HN wirklich von Vorteil, da in DB-Tabellen Felder selten lv_xxx heißen und somit die Doppeldeutigkeit noch weniger oft vorkommt.
Was man von den anderen neuen Paradigmen hÀlt ( INTO-Zusatz des SELECTs soll jetzt ans Ende des SELECT-Statements gestellt werden ) ist wohl Geschmackssache - ich zumindest habe mich daran gewöhnt.
DeathAndPain hat geschrieben:Inlinedeklaration mit ORDER BY .. INTO TABLE @DATA mit nachtrÀglichem READ TABLE...BINARY SEARCH
Ich bin ja gar nicht weit von D&P entfernt. Gefallen tut mit diese Kombination auch nicht. Aber ich bin darauf in folgender Konstellation gestoßen und mir ist (bis heute) keine sinnvolle Alternative eingefallen.
Ich muss einen Haufen! Felder von der DB selektieren ( hĂŒbscher JOIN oder was weiß ich - aber eben mehr als nur 10 oder 20 Felder ) aber ich weiß zum Zeitpunkt der Programmierung noch nicht welche Felder ich noch zusĂ€tzlich demnĂ€chst brauchen werde. (z.B. Weil der Fachbereich IMMER mehr haben will nachher ) Einige dieser Felder sind mir bekannte SchlĂŒsselfelder - der Rest wird einfach benötigt zum Anreichern von Daten. Einerseits möchte ich datensparsam umgehen und nicht einfach mittels * alles ĂŒber die DB-Schnittstelle jagen, andereseits brauche ich einen performanten Zugriff auf die Daten. Und sobald neue Felder benötigt werden habe ich keine Lust einen lokalen Datentyp zu erweitern und danach auch noch die SELECT-Bedingung zumal es fĂŒr mich so schöner zu sehen ist welche Felder denn von der DB selektiert werden.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Standardtabellen vs andere Tabellen, Inline-Deklaration beim SELECT usw.

Beitrag von a-dead-trousers (Top Expert / 3539 / 115 / 918 ) » 29.09.2020 08:19
Gegenvorschlag:
Anstatt derart komplizierte SELECTs (mit JOINS usw.) in Programmen zu machen, kann man das relativ leicht als View auch auf die Datenbank auslagern. Ganz egal ob man es jetzt in der SE11 direkt in SAP hinbekommt oder auf einen CDS-View in Eclipse (wegen der umfangreicheren Syntax) ausweichen muss, bekommt man damit doch gleich die Strukturdefinition im DDIC quasi geschenkt. Einen TYPES ... SORTED TABLE OF ... WITH ... entweder im Programmcode oder gleich als Tabellentyp im DDIC anzulegen ist dann auch nicht mehr der große Aufwand.
Das man die Objekte im DDIC wiederverwenden kann muss ich hier doch hoffentlich nicht extra erwÀhnen.
Mist! Jetzt Hab ich es doch getan. 😉
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.07
Basis: 7.40

Re: Standardtabellen vs andere Tabellen, Inline-Deklaration beim SELECT usw.

Beitrag von black_adept (Top Expert / 3421 / 66 / 664 ) » 29.09.2020 08:44
@adt. Im nicht wiederverwendbaren (hĂ€ufien) FAll könnte ich genauso gut einen lokalen Typ anlegen. Mir geht es darum mit möglichst wenig Aufwand und Redundanz die selektierte Datentabelle erweitern zu können. Bei Inlinedeklaration erweitere ich einfach die Feldliste oder packe einen weiteren Join hinzu und die Datentabelle erweitert sich automatisch mit. Ansonsten mĂŒsste ich erst den Typ erweitern und dann auch noch den SELECT...
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Standardtabellen vs andere Tabellen, Inline-Deklaration beim SELECT usw.

Beitrag von a-dead-trousers (Top Expert / 3539 / 115 / 918 ) » 29.09.2020 10:29
black_adept hat geschrieben: ↑
29.09.2020 08:44
Bei Inlinedeklaration erweitere ich einfach die Feldliste oder packe einen weiteren Join hinzu und die Datentabelle erweitert sich automatisch mit. Ansonsten mĂŒsste ich erst den Typ erweitern und dann auch noch den SELECT...
Bei (CDS-)Views erweitert man nur den View und hat dann auch automatisch die Feldliste UND den SELECT angepasst. Und selbst wenn man es nicht wiederverwendet, tut es ja IMHO nicht weh wenn man einen zusÀtzlichen View noch neben dem Report hat. Die liegen eh dann im selben Paket und durch einen Doppelklick springt man aus dem Editor in den View.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.07
Basis: 7.40

Re: Standardtabellen vs andere Tabellen, Inline-Deklaration beim SELECT usw.

Beitrag von DeathAndPain (Top Expert / 1438 / 156 / 330 ) » 29.09.2020 19:01
black_adept hat geschrieben:Mich stört tatsÀchlich das Wort "Regelfall" - aber nicht nur bei dir sondern auch bei SAP die mich zu hÀufig darauf hinweisen, dass ich evtl. kein "ORDER BY" in meinem SELECT habe.
Den brauchst Du ja auch nicht, wenn Deine Zieltabelle ordentlich als SORTED oder HASHED deklariert ist. 😜
black_adept hat geschrieben:Aber in meinen typischen Aufgaben kommt es eben dauernd vor, dass ich kurz eine kleine Customizingtabelle vorhalten muss wo sich ein SchlĂŒsselzugriff einfach nicht lohnt
Ich finde es trotzdem richtig, den SchlĂŒsselzugriff zu machen. Der TYPES-Befehl ist jetzt nicht die Schreibarbeit, und so schafft man einen definierten Rahmen im Programm, der spĂ€ter sich und anderen hilft, sich zu orientieren, wenn man nach einem halben Jahr nicht (mehr) genau aus dem Kopf weiß, wie die Customizingtabelle aufgebaut war. Zugleich macht es im Debugger die SchlĂŒsselwerte ĂŒbersichtlicher (da sortiert).
black_adept hat geschrieben:Hier bin ich halt ( und das ist eben oft der Fall ) schon gezwungen eine Standardtabelle zu verwenden einfach damit mir der AusgabeALV beim Sortieren nicht wegdumpt.
NatĂŒrlich gibt es AnwendungsfĂ€lle fĂŒr Standardtabellen. Ein- und Ausgabedateien die man parst oder erzeugt wĂ€ren ein weiteres Beispiel. Oder wenn man mal eine absteigende Sortierung fĂŒr eine Spalte benötigt (was auch fĂŒr Codingzwecke nĂŒtzlich sein kann, etwa wenn man nur den höchsten Wert behalten möchte und den Rest anschließend elegant mit einem DELETE ADJACENT DUPLICATES entsorgt (da dieser Befehl das erste Vorkommen behĂ€lt)). Aber es ist eben ein Unterschied, ob man sich Gedanken darĂŒber gemacht hat (und dies bei dem ALV oder der Datei vielleicht sogar mit TYPE STANDARD TABLE WITH EMPTY KEY im Code dokumentiert) oder ob man einfach sagt "Mach TYPE TABLE - ist egal, geht immer". WĂ€hrend man gerade entwickelt, steckt man tief drin in dem, was man da tut und blickt komplett durch. Aber wenn man spĂ€ter mal ran muss oder ein anderer, der vielleicht einen anderen Programmierstil pflegt, den Code lesen und verstehen muss, dann ist man fĂŒr jeden solchen hilfreichen Strohhalm dankbar. Der Code wird besser verstĂ€ndlich und ist dadurch leichter wartbar.
black_adept hat geschrieben:Was man von den anderen neuen Paradigmen hÀlt ( INTO-Zusatz des SELECTs soll jetzt ans Ende des SELECT-Statements gestellt werden ) ist wohl Geschmackssache - ich zumindest habe mich daran gewöhnt.
Die meisten Leute stellen es intuitiv hinter das FROM tabelle. Ich halte mich noch an das Format, das ich als die ursprĂŒngliche SQL-Syntax in Erinnerung habe und das damals bei Informix 4GL auch verpflichtend war: SELECT * INTO whatever FROM tabellenname. Aber das ist Geschmackssache. Wenn das das Problem ist, haben wir keins. Immerhin fĂ€llt dadurch ein Nebenbonbon fĂŒr mich ab: Da außer mir kein Schwein diese Reihenfolge verwendet, sehe ich bei jedem SELECT auf einen Blick, ob er von mir ist oder nicht. 😁
black_adept hat geschrieben:Und sobald neue Felder benötigt werden habe ich keine Lust einen lokalen Datentyp zu erweitern und danach auch noch die SELECT-Bedingung
Ist das wirklich so ein Aufwand, die neuen Feldnamen zweimal hinzuschreiben statt einmal? Das ist fĂŒr mich keine Rechtfertigung fĂŒr Konzessionen wie die Verwendung einer Standardtabelle, wo eine andere mehr Sinn gemacht hĂ€tte. Wenn man mit solch bisschen mehr Schreibarbeit eine bessere CodequalitĂ€t hinbekommt, sollte es einem die Sache allemal wert sein, finde ich.
black_adept hat geschrieben:zumal es fĂŒr mich so schöner zu sehen ist welche Felder denn von der DB selektiert werden.
Wo ist der Unterschied? Du hast die Felder doch trotzdem der Reihe nach im SELECT drin.
a_dead_trousers hat geschrieben:Anstatt derart komplizierte SELECTs (mit JOINS usw.) in Programmen zu machen, kann man das relativ leicht als View auch auf die Datenbank auslagern.
Das halte ich aus mehreren GrĂŒnden fĂŒr eine Verschlechterung. Zum einen packt man damit lokale Codeteile in das globale DDIC, das man damit vollmĂŒllt. Lokales sollte meiner Meinung nach lokal definiert sein und nicht in programmĂŒbergreifenden Verzeichnissen. Zum anderen ist der SELECT dann nicht mehr so gut lesbar. Man sieht dann einen SELECT aus einer Datenbanktabelle, die es gar nicht gibt (weil sie nĂ€mlich ein View ist), und wenn man sich ĂŒber die reale Herkunft der gelesenen Daten Aufschluss verschaffen möchte, muss man zur Maus greifen, per Doppelklick einsteigen, in der SE11 in mehreren Tabreitern recherchieren usw. In Eclipse ist das sogar noch unkomfortabler.

Ich mag keine MedienbrĂŒche (dazu gehört auch der Handwechsel zwischen Tastatur und Maus). Wenn da ein SELECT mit mehreren JOINS steht, dann kann ich daran sehr schön nachvollziehen, wo welche Werte genau herkommen. Genau an der Stelle im Code, an der ich mich befinde und ohne in irgendwelche Unterfenster abspringen und darin dann noch Tabreiter durchwĂŒhlen zu mĂŒssen.

Überdies habe ich mal gelesen, dass SAP-Views gar keine SQL-Joins aufspannen, sondern UNIONs. Ich habe das nicht genauer recherchiert, tippe aber, dass Unions langsamer sind als klare Joins. (Die SAP-Tabellenpufferung umgehen Unions meines Wissens auf jeden Fall.)
a_dead_trousers hat geschrieben:Das man die Objekte im DDIC wiederverwenden kann muss ich hier doch hoffentlich nicht extra erwÀhnen.
Wenn man sie denn wiederfindet, wenn man ein Jahr spĂ€ter vor einem vergleichbaren Problem steht. Und selbst dann wĂ€re es riskant, denn dadurch wĂŒrde man die beiden unterschiedlichen Programme miteinander verschweißen: Die Änderung der Deklaration im einen Programm Ă€ndert das andere mit, wenn die Änderung sich im DDIC abspielt.

Die SAP kriegt es doch nicht mal hin, sich auf einen FB z.B. fĂŒr die Ermittlung des letzten Tages eines Monats zu einigen. Wie oft haben sie das (mit völlig unterschiedlichen CodingansĂ€tzen) implementiert? Da wĂ€ren lokale Formroutinen klar besser gewesen, denn ganz offensichtlich findet der eine Entwickler den FB des anderen sowieso nicht wieder, obwohl diese FunktionalitĂ€t offenkundig an sehr vielen Stellen gebraucht wird, so dass in dem Fall ein globales Coding im Prinzip durchaus Sinn ergibt.

Ich bleibe dabei: Lokale Daten gehören nach meiner Überzeugung lokal definiert.

Seite 1 von 1

Über diesen Beitrag



UnterstĂŒtze die Community und teile den Beitrag fĂŒr mehr Leser und besseren Inhalt:

Vergleichbare Themen

Interne Tabelle als Inline Deklaration?
von tekko » 08.09.2020 14:31
SAP Standardtabellen
von damicl » 18.11.2010 10:41
PDF im Browser (inline)
von pynsy » 05.07.2004 20:43
Transaktion ME81N, beim Inline-Aufruf MS EXCEL keine Daten
von sigmund » 17.06.2003 15:20
Select auf zwei Tabellen
von mip » 27.03.2008 16:05