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.