ABAP Clean Code

Re: ABAP Clean Code

@Ralf: ich fand das Beispiel gut.
Bei Sortierungen u.ä. sehe ich die Anwendung auch sofort (und den Sinn, es nicht auf den Datenbankserver machen zu lassen).

Schwerer vorstellbar wird es für mich, wenn es um Auswertungen geht: da habe ich ggfs. mehrere Tabellen, die nicht zu einem Objekt gehören aber in Beziehung zu einander stehen. Und dort wären speziell gebaute Joins, die gleich die Menge der Daten radikal einschränken, hilfreich. Passt für mich aber nicht so zu "Persistenzklasse für einzelne Tabelle" oder "Persistenzklasse für ein Geschäftsobjekt".

Wie würdest Du das angehen?

Re: ABAP Clean Code

Redefinition der SELECT-Methode

Eine etwas generische Antwort... :-)

Was ich meinte: wenn man anfängt und für seine Geschäftsobjekte, oder für einzelne Tabellen, jeweils eine Persistenzklasse zu stricken, die gerne viel Komplexität abfackeln und vor dem Aufrufer verbergen darf (wäre ja einer der Vorteile) und nun die Anforderung hat, eine Auswertung zu bauen, die sich
a) die Daten aus mehreren Quellen (Persistenzklassen, bzw. am Ende Tabellen) beschaffen muss und
b) sich Joins geradezu anbieten, um Treffermenge und Datenmenge einzuschränken
Also Tabelle A und B und ihre Persistenzklassen CLA und CLB.
Dann finde ich es "unschön", einen Join der A und B betrifft in CLA oder CLB unterzubringen. Die Daten erst über CLA und CLB zusammenzulesen und dann erst einzudampfen, dürfte auch ungeschickt sein.
Bleibt, hierfür eine spezialisierte Persistenzklasse CLAB zu bauen. Oder?

Re: ABAP Clean Code

Darum geht es ja gar nicht, es geht darum, dass viele mit Cluster-Tabellen gar nicht umgehen können

Zum Glück ist das auch nicht mehr wirklich notwendig, da die SAP Clustertabellen schon vor geraumer Zeit für deprecated erklärt hat und eine nach der anderen in transparente Tabellen umwandelt.

Re: ABAP Clean Code

ralf.wenzel hat geschrieben: ↑

24.05.2019 18:46

Trotzdem kann man sie gut gebrauchen, um beliebig (!) strukturierte Daten abzulegen.
Ralf

Kann ich nur bestätigen. Persönlich bevorzuge ich inzwischen stattdessen Tabellen mit einem Stringfeld als zentrale Datenablage, da man eigentlich all das was man in ein Cluster schreiben kann via ID-Transformation in einen String oder zurück umwandeln kann

Re: ABAP Clean Code

black_adept hat geschrieben: ↑

25.05.2019 22:08

Kann ich nur bestätigen. Persönlich bevorzuge ich inzwischen stattdessen Tabellen mit einem Stringfeld als zentrale Datenablage, da man eigentlich all das was man in ein Cluster schreiben kann via ID-Transformation in einen String oder zurück umwandeln kann

Richtig, habe ich auch schon gemacht. XML in Stringtab. Ich überlege derzeit, was besser ist.

deejey hat geschrieben: ↑

26.05.2019 01:05

Ist das euer Ernst? Wie wertet ihr das aus?

Ich verstehe die Frage nicht. Satz einlesen, XML zurück transformieren und mit dem so erhaltenen Datenobjekt arbeiten.



Ralf

Re: ABAP Clean Code

ralf.wenzel hat geschrieben: ↑

26.05.2019 07:53

black_adept hat geschrieben: ↑

25.05.2019 22:08

Kann ich nur bestätigen. Persönlich bevorzuge ich inzwischen stattdessen Tabellen mit einem Stringfeld als zentrale Datenablage, da man eigentlich all das was man in ein Cluster schreiben kann via ID-Transformation in einen String oder zurück umwandeln kann

Richtig, habe ich auch schon gemacht. XML in Stringtab. Ich überlege derzeit, was besser ist.

deejey hat geschrieben: ↑

26.05.2019 01:05

Ist das euer Ernst? Wie wertet ihr das aus?

Ich verstehe die Frage nicht. Satz einlesen, XML zurück transformieren und mit dem so erhaltenen Datenobjekt arbeiten.

Wie darf ich mir das vorstellen? Ich habe komplexe Datenobjekte, welche ich als XML-String mit eindeutiger ID in einer Tabelle speichere und per Transformation lesen/schreiben kann. Gehen wir als einfaches Beispiel von einem Lieferscheinobjekt aus. Wenn ich nun zu einem Lieferzeitraum die Menge von spezifischen ausgelieferten Materialien ermitteln möchte würde ich ja nicht sämtlich vorhandene Objekte transformieren und anhand Kopf- sowie Positionskriterium auswerten wollen. Werden dann auswertungsrelevante Daten zusätzlich in Tabellenfelder gespeichert? Aber das wäre ja eine gewaltige Datenredundanz.

Re: ABAP Clean Code

IHe hat geschrieben: ↑

27.05.2019 13:28

Wie darf ich mir das vorstellen? Ich habe komplexe Datenobjekte, welche ich als XML-String mit eindeutiger ID in einer Tabelle speichere und per Transformation lesen/schreiben kann. Gehen wir als einfaches Beispiel von einem Lieferscheinobjekt aus. Wenn ich nun zu einem Lieferzeitraum die Menge von spezifischen ausgelieferten Materialien ermitteln möchte würde ich ja nicht sämtlich vorhandene Objekte transformieren und anhand Kopf- sowie Positionskriterium auswerten wollen. Werden dann auswertungsrelevante Daten zusätzlich in Tabellenfelder gespeichert? Aber das wäre ja eine gewaltige Datenredundanz.

Clustertabellen werden in der Regel als "Datengrab" verwendet und nicht als Stamm- oder Bewegungsdatenspeicher. Immer mal wieder kommt es vor, dass man einen "Programmzustand" protokollieren möchte, weil an bestimmten Stellen "irgendwas" nicht so funktioniert, wie gedacht. Dann ist es sehr einfach, alle Objekte, Strukturen und/ oder interne Tabellen zu serialisieren und unter der Objekt-ID + Timestamp + User + ApplicationServer abzuspeichern. Wenn du hier für jede intern definierte Tabelle oder Struktur eine eigene Datenbanktabelle erstellen möchtest, dann die Daten in den entsprechenden Tabellen speichern und hinterher wieder sinnvoll zusammen setzen möchtest... Dann viel Spaß... ;)

Hier ein paar Links zu der Serialisierung:
https://www.volker-wegert.de/en/content ... -idontwork
https://tricktresor.de/blog/serialize-me/
https://rvanmil.wordpress.com/2011/05/20/serialization/

Wofür man das dann letztendlich benötigt, weiß man meistens erst, wenn es soweit ist.

Die Vorteile der Serialisierung und Deserialisierung per CALL TRANSFORMATION id ggü. {EXPORT TO / IMPORT FROM} DATABASE abc(id):
* Sehr variabel/ robust. Du kannst Felder aus der Struktur entfernen oder hinzufügen und die Deserialisierung funktioniert trotzdem.
* Klartext. Zur Not, wenn doch irgendwas nicht funktionieren sollte, kannst du dir den String als Text anzeigen lassen und hast die Informationen.

Die Serialisierung ist sehr schnell. Keine Ahnung, ob sie schneller ist, als die Speicherung in einer Clustertabelle. Müsste man mal ausprobieren.

Obwohl die De-/Serialisierung von Klasseninstanzen funktioniert, klappt das leider nicht mit GUI-Controls. Das wäre sonst sehr schön, wenn man ein Control einfach unter Angabe eines neuen PARENT wieder Deserialisieren könnte... ;)