Sortierter Tabellentyp für Objekttabelle

Die Objektorientierung mit ABAP®: Vererbung, Dynamische Programmierung, GUI Controls (u.a. ALV im OO).
17 Beiträge Seite 1 von 2 (current) Nächste
17 Beiträge Seite 1 von 2 (current) Nächste

Sortierter Tabellentyp für Objekttabelle

Beitrag von ralf.wenzel (Top Expert / 3472 / 155 / 223 ) » 11. Sep 2019 12:15

Moin,

ich möchte gern eine Tabelle haben, Typ "sortierte Tabelle" mit eindeutigem Schlüssel. Zeilentyp ist die Instanz einer Klasse. Schlüsselfeld ist ein Attribut des Objektes. Soweit das Soll.

Einen solchen Schlüssel schaffe ich aber nicht zu deklarieren, ich wandere von Fehlermeldung zu Fehlermeldung. Ich habe offensichtlich keine andere Wahl, als die gewünschten Schlüsselfelder als Strukturfelder anzulegen (dann muss ich sie aber auch ständig befüllen, was zu redundanten Daten führt).

Richtig?


Ralf


Re: Sortierter Tabellentyp für Objekttabelle

Beitrag von a-dead-trousers (Top Expert / 3284 / 90 / 837 ) » 11. Sep 2019 12:50

Leider richtig 😕
Das warum kann ich mir aber auch recht gut erklären:
Eine Objektinstanz liegt im HEAP und in der Tabelle ist eigentlich nur ein Zeiger darauf.
Somit kann die Tabellenzeile den Zustand "not bound" einnehmen und der Tabellenschlüssel würde somit "undefiniert".
Wenn man beim Ändern eines Attributes auch noch aufpasen müsste, dass dadurch irgendeine Schlüsselverletzung in einer Tabelle, die man aufgrund von "sauberen Interfaces" uU gar nicht im Zugriff hat, passieren könnte würde das IMHO auch recht schnell verwirrend werden. Ganz zu Schweigen davon ob sich so eine Prüfung im Kernel zwischen HEAP und NON-HEAP überhaupt realisieren lässt.
Schon jetzt frage ich mich hin und wieder warum ein Kurzdump kommt obwohl ich nur eine Spalte ändere, bis ich dann nach längerem Suchen im Aufrufstack eine sortierte Tabelle oder ähnliches entdecke, das den Parameter "implizit" auf "Read-only" setzt.

Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag (Insgesamt 5):
ralf.wenzel (11. Sep 2019 12:59) • Icke0801 (11. Sep 2019 14:23) • tm987456 (11. Okt 2019 11:38) • SaskuAc (7. Nov 2019 07:33) • Legxis (7. Nov 2019 08:50)

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: Sortierter Tabellentyp für Objekttabelle

Beitrag von ralf.wenzel (Top Expert / 3472 / 155 / 223 ) » 11. Sep 2019 12:59

Besser hätte man das wohl kaum erklären können


Ralf

Re: Sortierter Tabellentyp für Objekttabelle

Beitrag von ewx (Top Expert / 4065 / 177 / 399 ) » 6. Nov 2019 23:08

Code: Alles auswählen.

REPORT.
CLASS xyz DEFINITION.
  PUBLIC SECTION.
    METHODS constructor IMPORTING name TYPE string.
    DATA name TYPE string.
ENDCLASS.
CLASS xyz IMPLEMENTATION.
  METHOD constructor.
    me->name = name.
  ENDMETHOD.
ENDCLASS.

TYPES ty TYPE SORTED TABLE OF REF TO xyz WITH UNIQUE KEY table_line.
DATA tab TYPE ty.

START-OF-SELECTION.

*TRY.
*    DATA(obj) =  tab[ table_line->name = 'HUGO'  ].
*  CATCH cx_sy_itab_line_not_found.
*ENDTRY.

  tab = VALUE #( ( NEW #( 'HUGO' ) ) ).
  READ TABLE tab
  INTO DATA(line)
  WITH KEY table_line->name = 'HUGO'.
  IF sy-subrc = 0.
    MESSAGE 'HUGO found' TYPE 'S'.
  ENDIF.

Re: Sortierter Tabellentyp für Objekttabelle

Beitrag von ralf.wenzel (Top Expert / 3472 / 155 / 223 ) » 6. Nov 2019 23:48

So kriege ich natürlich einen mörderbreiten Schlüssel mit allen Nachteilen dir das mit dich bringt.


Ralf

Re: Sortierter Tabellentyp für Objekttabelle

Beitrag von ewx (Top Expert / 4065 / 177 / 399 ) » 7. Nov 2019 00:26

irgendwie hast du auch immer was zu meckern...

Re: Sortierter Tabellentyp für Objekttabelle

Beitrag von a-dead-trousers (Top Expert / 3284 / 90 / 837 ) » 7. Nov 2019 07:42

ewx hat geschrieben:
6. Nov 2019 23:08

Code: Alles auswählen.

TYPES ty TYPE SORTED TABLE OF REF TO xyz WITH UNIQUE KEY table_line.
Naja, überspitzt formuliert definierst du damit nur eine Tabelle in der man nicht zweimal dieselbe Objektinstanz einfügen kann. Einen optimierten Suchzugriff hat man so nur wenn man eine der Instanzen kennt. Also wenn man wissen möchte ob die Instanz schon vorhanden ist. Einen Schlüssel für den schnellen Zugriff auf die Attribute der Instanzen kann man damit nicht erreichen.

ralf.wenzel hat geschrieben:
6. Nov 2019 23:48
So kriege ich natürlich einen mörderbreiten Schlüssel mit allen Nachteilen dir das mit dich bringt.
Nicht so ganz. Der Schlüssel ist der Instanzzeiger (INT4?).
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: Sortierter Tabellentyp für Objekttabelle

Beitrag von a-dead-trousers (Top Expert / 3284 / 90 / 837 ) » 7. Nov 2019 07:51

Was aber geht ist die alte SORT BY und dann BINARY SEARCH Krücke für STANDARD TABLE:

Code: Alles auswählen.

TYPES ty TYPE STANDARD TABLE OF REF TO xyz WITH DEFAULT KEY.
DATA: instance_tab TYPE ty.
APPEND NEW #( ) TO instance_tab.
SORT instance_tab BY table_line->name.
READ TABLE instance_tab REFERENCE INTO DATA(instance) BINARY SEARCH
  WITH KEY table_line->name = ''.
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: Sortierter Tabellentyp für Objekttabelle

Beitrag von ralf.wenzel (Top Expert / 3472 / 155 / 223 ) » 7. Nov 2019 08:04

....was aber nicht das ist, was ich mir unter einem optimierten Zugriff vorstelle, weil man die Tabelle potentiell bei jedem Zugriff umsortieren muss.


Ralf

Re: Sortierter Tabellentyp für Objekttabelle

Beitrag von DeathAndPain (Top Expert / 1157 / 132 / 251 ) » 7. Nov 2019 08:17

Tja, das OO-Geraffel ist halt schön abstrakt, aber performancetechnisch ineffizient. Einen Tod musst Du sterben.
a-dead-trousers hat geschrieben:TYPES ty TYPE STANDARD TABLE OF REF TO xyz WITH DEFAULT KEY.
Was willst Du mit dem DEFAULT KEY, mit dem machst Du doch eh nix, sondern nutzt ganz andere Spalten als effektiven Suchschlüssel. Da wäre WITH EMPTY KEY ehrlicher.

Re: Sortierter Tabellentyp für Objekttabelle

Beitrag von ewx (Top Expert / 4065 / 177 / 399 ) » 7. Nov 2019 08:37

DeathAndPain hat geschrieben:
7. Nov 2019 08:17
Tja, das OO-Geraffel ist halt schön abstrakt, aber performancetechnisch ineffizient.
du kannst es auch nicht lassen, oder? 🙃

Dafür, dass du in deinen sonstigen Aussagen sehr klar und spezifisch bist, bist du, sobald es irgendwie mit Klassen zu tun hat, herrlich polemisch.

Ja, performancetechnisch ist das Konstrukt wahrscheinlich nicht der Brüller. Der Schlüssel ist wahrscheinlich der Instanzzähler, insofern kann man sich die Key-Definition mit Table_line tatsächlich sparen.
Die Zugriffsgeschwindigkeit ist ähnlich, egal ob

Code: Alles auswählen.

TYPE SORTED TABLE OF REF TO xyz WITH UNIQUE KEY table_line.
oder

Code: Alles auswählen.

TYPE STANDARD TABLE OF REF TO xyz with EMPTY KEY.
(Getestet mit 10.000.000 Einträgen)

Mir war es erstmal wichtig, dass man überhaupt mit dem READ auf Attribute der Instanz zugreifen kann. Wenn es dann wirklich auf Performance ankommt, muss man halt eine umständliche Deklaration der Tabellenzeile vornehmen mit dem Nachteil der doppelten Datenhaltung und umständlichen Handling, wenn sich ein Schlüsselwert ändern sollte.

Mir ist es in erster Linie wichtig, dass die Programme so einfach wie möglich und möglichst gut lesbar sind. Je einfacher die zugrunde liegende Datendeklaration ist, desto potentiell einfacher ist also auch das Programm. Da sind mir ein paar Millisekunden im 98% der Fälle echt egal.

Meine Tests habe ich mit einer zugegeben sehr einfachen und kleinen Klasse gemacht. Kann sein, dass sich die Zugriffen exponentiell verschlechtern, wenn man wirklich große Objektreferenzen so verwaltet.

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
Legxis (7. Nov 2019 08:54)


Re: Sortierter Tabellentyp für Objekttabelle

Beitrag von ewx (Top Expert / 4065 / 177 / 399 ) » 7. Nov 2019 08:38

ralf.wenzel hat geschrieben:
7. Nov 2019 08:04
....was aber nicht das ist, was ich mir unter einem optimierten Zugriff vorstelle, weil man die Tabelle potentiell bei jedem Zugriff umsortieren muss.
Warum musst du die Tabelle bei jedem Zugriff umsortieren?

Re: Sortierter Tabellentyp für Objekttabelle

Beitrag von ralf.wenzel (Top Expert / 3472 / 155 / 223 ) » 7. Nov 2019 08:49

Ich schrieb "potentiell" - Wenn ich erst nach Attribut A und dann nach Attribut B sortieren muss, weil der erste Zugriff nach Attribut A und der zweite nach Attribut B erfolgt.


Ralf

Re: Sortierter Tabellentyp für Objekttabelle

Beitrag von a-dead-trousers (Top Expert / 3284 / 90 / 837 ) » 7. Nov 2019 09:13

Nicht zu vergessen, wenn man neue Einträge hinzufügt oder ein Instanzattribut ändert.
Da behelfe ich meistens mit einem ON_CHANGED Ereignis.
Wenn eine Instanz "bemerkt", dass sich ein Attribut geändert hat (geht natürlich nur bei PUBLIC READ-ONLY mit eigener SET-Methode), wird das Ereignis gefeuert und die Instanz, welche die Tabelle mit den Instanzen beinhaltet, sortiert dann neu.
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: Sortierter Tabellentyp für Objekttabelle

Beitrag von ralf.wenzel (Top Expert / 3472 / 155 / 223 ) » 7. Nov 2019 09:52

Warum muss das PUBLIC sein?

Ralf

Seite 1 von 2 (current) Nächste