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 / 1795 / 213 / 396 ) »
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! 😄

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


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

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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 / 4271 / 213 / 1140 ) »
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.18
Basis: 7.50

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

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
@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 / 4271 / 213 / 1140 ) »
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.18
Basis: 7.50

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

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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

Vergleichbare Themen

1
Antw.
1313
Views
Interne Tabelle als Inline Deklaration?
von tekko » 08.09.2020 14:31 • Verfasst in ABAP® für Anfänger
8
Antw.
21168
Views
SAP Standardtabellen
von damicl » 18.11.2010 10:41 • Verfasst in ABAP® Core
6
Antw.
4300
Views
PDF im Browser (inline)
von pynsy » 05.07.2004 20:43 • Verfasst in Web-Dynpro, BSP + BHTML
9
Antw.
464
Views
Updaten von Standardtabellen
von BecomingAnAbapGuru » 28.09.2022 09:03 • Verfasst in ABAP® für Anfänger
2
Antw.
291
Views
Z-Felder in Standardtabellen
von ZF_SAPler » 07.07.2022 17:50 • Verfasst in ABAP® für Anfänger

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.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141