Tabelle in Tabelle - geschachtelte Tabelle
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Beitrag
von p.suedfeld (ForumUser / 3 / 0 /
0
)
»
Hallo zusammen,
ich habe folgende Aufgabe bekommen:
Ich soll eine geschachtelte Struktur erstellen. Also quais eine Tabelle, in der in einer Spalte wiederrum Tabellen zu den einzelnen Datensätzen liegen.
Für interne Tabellen habe ich das schon gelöst:
Jetzt möchte ich eine physische Tabelle anlegen, die genau das repräsentiert.
Geht das überhaupt? Wenn ja, wie?
Besten Dank für die Unterstützung im Voraus!
ich habe folgende Aufgabe bekommen:
Ich soll eine geschachtelte Struktur erstellen. Also quais eine Tabelle, in der in einer Spalte wiederrum Tabellen zu den einzelnen Datensätzen liegen.
Für interne Tabellen habe ich das schon gelöst:
Code: Alles auswählen.
TYPES:
BEGIN OF MEASTYP,
intreno TYPE VIBDMEAS-INTRENO,
meas TYPE VIBDMEAS-MEAS,
validto TYPE VIBDMEAS-VALIDTO,
validfrom TYPE VIBDMEAS-VALIDFROM,
measvaluecmpl TYPE VIBDMEAS-MEASVALUECMPL,
measunit TYPE VIBDMEAS-MEASUNIT,
END OF MEASTYP.
* Bemessungentabellentyp
TYPES: meas_tbl_type TYPE TABLE OF MEASTYP WITH NON-UNIQUE KEY intreno meas validto.
* Mietobjekttyp mit Spalte vom Typ Bemessungentabelle
TYPES:
BEGIN OF MOTYP,
bukrs TYPE VIBDRO-BUKRS,
swenr TYPE VIBDRO-SWENR,
smenr TYPE VIBDRO-SMENR,
xmetxt TYPE VIBDRO-XMETXT,
responsible TYPE VIBDRO-RESPONSIBLE,
meas_tbl TYPE meas_tbl_type,
END OF MOTYP.Geht das überhaupt? Wenn ja, wie?
Besten Dank für die Unterstützung im Voraus!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo,
soweit ich weiß, geht das bei Datenbanktabellen nicht.
Im DDIC kann man solche Strukturen, die Tabellen enthalten definieren, indem man Tabellentypen benutzt (ist noch einfacher als im Coding).
Will man die Tabelle zur Tabellenzeile speichern, so würde ich eine zweite Tabelle machen, die den Datensätzen den Tabellenschlüssel der Haupttabelle voranstellt ... (so wie man das immer schon gemacht hat!).
Gruß
babp
soweit ich weiß, geht das bei Datenbanktabellen nicht.
Im DDIC kann man solche Strukturen, die Tabellen enthalten definieren, indem man Tabellentypen benutzt (ist noch einfacher als im Coding).
Will man die Tabelle zur Tabellenzeile speichern, so würde ich eine zweite Tabelle machen, die den Datensätzen den Tabellenschlüssel der Haupttabelle voranstellt ... (so wie man das immer schon gemacht hat!).
Gruß
babp
Beitrag
von p.suedfeld (ForumUser / 3 / 0 /
0
)
»
Danke für die raschen Antworten! 
Eigentlich würde mein Datenmodell auch eine relationale Speicherung der Daten in der DB aufheben...
Über die Strukturen im DDIC habe ich das auch schon abdecken können.
Aber wenn das Speichern in der Form - wie ich es verstanden habe - nicht geht, dann bin ich auch zufrieden...
Eigentlich würde mein Datenmodell auch eine relationale Speicherung der Daten in der DB aufheben...
Über die Strukturen im DDIC habe ich das auch schon abdecken können.
Aber wenn das Speichern in der Form - wie ich es verstanden habe - nicht geht, dann bin ich auch zufrieden...
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Hallihallo,
so ganz richtig ist deine letzte Aussage nicht.
Aber sehr häufig ist der von babap vorgeschlagene Weg die beste Alternative und man sollte auch versuchen so vorzugehen. Der Grund ist eben, dass du im DDIC keine tiefen Strukturen als Tabelle anlegen kannst sondern nur flache Strukturen.
Aber speichern kannst du solche tiefen Strukturen schon indem du ein "EXPORT TO DATABASE" machst.
Da das allerdings andere Nachteile hat sollte man sich gut überlegen ob das wirklich nötig ist oder ob man es nicht mit ein wenig Umstellung des codes/Ansatzes auf die andere Vorgehensweise mit den verschiedenen Tabellen zurückgehen kann.
so ganz richtig ist deine letzte Aussage nicht.
Aber sehr häufig ist der von babap vorgeschlagene Weg die beste Alternative und man sollte auch versuchen so vorzugehen. Der Grund ist eben, dass du im DDIC keine tiefen Strukturen als Tabelle anlegen kannst sondern nur flache Strukturen.
Aber speichern kannst du solche tiefen Strukturen schon indem du ein "EXPORT TO DATABASE" machst.
Da das allerdings andere Nachteile hat sollte man sich gut überlegen ob das wirklich nötig ist oder ob man es nicht mit ein wenig Umstellung des codes/Ansatzes auf die andere Vorgehensweise mit den verschiedenen Tabellen zurückgehen kann.
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Hallo,
das ist eigentlich recht einfach. Du suchst dir eine Clustertabelle ( in einem Testsytem z.B. die INDX ) und einen freien Bereich und schreibst deine Daten da rein.
Wenn du in deinem Beispiel z.B. eine Variable MODAT vom Typ MOTYP ( das ist die tiefe Struktur ) hast, könntest du z.B. mit
EXPORT modat TO DATABASE INDX(ZX) ID modat_key die ganze Struktur auf der Datenbank ablegen. Einfach mal die Doku zu dem Befehl EXPORT .. TO DATABASE durchlesen.
und später wieder mit IMPORT modat FROM DATABASE INDX(ZX) ID modat_key reimportieren.
Wenn du sowas aber produktiv einsetzt bitte eine eigene Clustertabelle anlegen ( im schlimmsten Fall Kopie der INDX machen ) statt Verwendung der INDX.
Ich verwende so etwas machmal als eine Art Datenpuffer, wenn ich für laufzeitintensive Berechnungen für ein Objekt eine Zeitlang das Ergebnis für andere Prozesse vorhalten möchte.
das ist eigentlich recht einfach. Du suchst dir eine Clustertabelle ( in einem Testsytem z.B. die INDX ) und einen freien Bereich und schreibst deine Daten da rein.
Wenn du in deinem Beispiel z.B. eine Variable MODAT vom Typ MOTYP ( das ist die tiefe Struktur ) hast, könntest du z.B. mit
EXPORT modat TO DATABASE INDX(ZX) ID modat_key die ganze Struktur auf der Datenbank ablegen. Einfach mal die Doku zu dem Befehl EXPORT .. TO DATABASE durchlesen.
und später wieder mit IMPORT modat FROM DATABASE INDX(ZX) ID modat_key reimportieren.
Wenn du sowas aber produktiv einsetzt bitte eine eigene Clustertabelle anlegen ( im schlimmsten Fall Kopie der INDX machen ) statt Verwendung der INDX.
Ich verwende so etwas machmal als eine Art Datenpuffer, wenn ich für laufzeitintensive Berechnungen für ein Objekt eine Zeitlang das Ergebnis für andere Prozesse vorhalten möchte.
Hallo,
hört sich an, als ob es funktioniert.
Aber im Prinzip macht man da nichts anderes, als daß man einen Schwung Daten zu einem Primärkey "ablädt". (Genau wie mit der Sekundärtabelle).
Cluster- oder Pooltabellen sind noch ein Überbleibsel aus der ganz ganz vergangenen SAP-Vergangenheit (weil die Dinger an einigen Stellen so ins Coding verstrickt sind, daß man sie nicht in andere Tabellen uwandeln kann ...).
Ich denke, das kann mit heutiger Technik anders gelöst werden.
Da fällt mir der SAP-Persistenzdienst ein.
Der holt Objekte von der Datenbank und kann "notfalls" noch ein paar weitere Tabellen dazulesen oder "abladen", wenn notwendig.
Ja, wenn ich es jetzt recht überlege, würde ich die o.a. Problemstellung so angehen.
Gruß
babap
P.S. Für prozessübergreifende Datenhaltung kann man übrigens die persistenten Objekte auch ins übergreifende SAP-Memory stellen. Dann kann jede Task, jeder Prozess zu jeder Zeit auf aktuelle Daten zugreifen. Entweder sind sie schon da und aktuell, oder sie werden von der DB geholt und bereitgestellt. Änderungen sind erstmal im Memory und jeder holt sie dort ab. Sie werden bei Commit-Work auf der DB nachgezogen. So hat jeder Prozess, jedes Modul, jede Routine, jedes Programm den aktuellen Stand, ohne, daß immer wieder auf der DB nachgesehen werden muß ob sich da was geändert hat.
Wenn sich kein Prozess "mehr dafür interessiert" werden die Daten vom Garbage-Collector abgeräumt.
hört sich an, als ob es funktioniert.
Aber im Prinzip macht man da nichts anderes, als daß man einen Schwung Daten zu einem Primärkey "ablädt". (Genau wie mit der Sekundärtabelle).
Cluster- oder Pooltabellen sind noch ein Überbleibsel aus der ganz ganz vergangenen SAP-Vergangenheit (weil die Dinger an einigen Stellen so ins Coding verstrickt sind, daß man sie nicht in andere Tabellen uwandeln kann ...).
Ich denke, das kann mit heutiger Technik anders gelöst werden.
Da fällt mir der SAP-Persistenzdienst ein.
Der holt Objekte von der Datenbank und kann "notfalls" noch ein paar weitere Tabellen dazulesen oder "abladen", wenn notwendig.
Ja, wenn ich es jetzt recht überlege, würde ich die o.a. Problemstellung so angehen.
Gruß
babap
P.S. Für prozessübergreifende Datenhaltung kann man übrigens die persistenten Objekte auch ins übergreifende SAP-Memory stellen. Dann kann jede Task, jeder Prozess zu jeder Zeit auf aktuelle Daten zugreifen. Entweder sind sie schon da und aktuell, oder sie werden von der DB geholt und bereitgestellt. Änderungen sind erstmal im Memory und jeder holt sie dort ab. Sie werden bei Commit-Work auf der DB nachgezogen. So hat jeder Prozess, jedes Modul, jede Routine, jedes Programm den aktuellen Stand, ohne, daß immer wieder auf der DB nachgesehen werden muß ob sich da was geändert hat.
Wenn sich kein Prozess "mehr dafür interessiert" werden die Daten vom Garbage-Collector abgeräumt.
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Hallo babap,
Clustertabellen sind m.E. mitnichten ein Relikt aus der Vergangenheit ( Pooltabellen vielleicht schon ), da man hier Sachen machen kann, die sonst nur schwer oder fast gar nicht ausführbar wären.
So ist die Ablage von Daten mit wechselnder Struktur in eine Tabelle mit fester Struktur eben nur sehr schwierig zu realisieren.
Beispiele:
Funktionsbausteine ( SE37 ) - Dort das Testdatenverzeichnis. Die Testdaten werden in einer einzigen Tabelle festgehalten für alle Funktionsbausteine. Egal was dort als Übergabeparameter definiert ist
Varianten: Aufgrund der vielen Möglichkeiten Selektionsoptionen/Parameter zu definieren ist es halt am einfachsten sich alle Eingabefelder inkl. ihrer aktuellen Belegung ( und bei SelOpts sind das dann halt Tabellen ) zu merken
Auch wenn man Variablen mit generischem Typ ( untypisierte Feldsymbole, Übergabeparameter vom Typ "Table" ) abspeichern möchte eignen sich Clustertabellen hervorragend.
Clustertabellen sind m.E. mitnichten ein Relikt aus der Vergangenheit ( Pooltabellen vielleicht schon ), da man hier Sachen machen kann, die sonst nur schwer oder fast gar nicht ausführbar wären.
So ist die Ablage von Daten mit wechselnder Struktur in eine Tabelle mit fester Struktur eben nur sehr schwierig zu realisieren.
Beispiele:
Funktionsbausteine ( SE37 ) - Dort das Testdatenverzeichnis. Die Testdaten werden in einer einzigen Tabelle festgehalten für alle Funktionsbausteine. Egal was dort als Übergabeparameter definiert ist
Varianten: Aufgrund der vielen Möglichkeiten Selektionsoptionen/Parameter zu definieren ist es halt am einfachsten sich alle Eingabefelder inkl. ihrer aktuellen Belegung ( und bei SelOpts sind das dann halt Tabellen ) zu merken
Auch wenn man Variablen mit generischem Typ ( untypisierte Feldsymbole, Übergabeparameter vom Typ "Table" ) abspeichern möchte eignen sich Clustertabellen hervorragend.
Hallo,
jetzt kommen wir zum Thema "eine Tabelle für alles mögliche". Und dann nach Kontext unterschiedlich interpretiert.
Das Ganze gab es schon vor vielen Jahren und nannte sich "Satzart" und diente dazu, in einem Schwung Lochkarten verschiedene Statzstrukturen einlesen zu können ...
Abgesehen von persönlichen Präferenzen und dem einen oder anderen Spezialfall halte ich diese Form der Datenverwaltung nicht mehr für "alltagstauglich" oder programmierfreundlich oder lesefreundlich.
Im letzten Projekt habe ich zwar Rohdaten aus verschiedensten CSV-Dateien alle in einer einzigen Tabelle abgespeichert. (auch hier gab es einen Typ oder eben die Satzart).
Die interpretierten Daten (auseinandergefuselt) wurden aber in einer Struktur gespeichert, die alle möglichen Felder enthielt. Mal waren sie gefüllt, mal nicht.
Da sich bei einem SAP-System die darunterliegende Datenbank um das Wegoptimieren von Blanks, Nullen und sonstigen leeren Felder kümmert, und die Felder und Tabellen doch pysikalisch irgendwie- und -woanders abspeichert, als SAP uns glauben machen will, kann ich mir die Strukturen auch so machen, daß ich sie verstehe und debuggen oder im Klartext lesbar machen kann (se16...).
Aber hin und wieder ist man tatsächlich auf ein paar extrem individuelle und spezielle Dinge angewiesen und dann ist es gut, daß man weiß, wo man nachsehen muß (www. abapforum.com)
Gruß
babap
jetzt kommen wir zum Thema "eine Tabelle für alles mögliche". Und dann nach Kontext unterschiedlich interpretiert.
Das Ganze gab es schon vor vielen Jahren und nannte sich "Satzart" und diente dazu, in einem Schwung Lochkarten verschiedene Statzstrukturen einlesen zu können ...
Abgesehen von persönlichen Präferenzen und dem einen oder anderen Spezialfall halte ich diese Form der Datenverwaltung nicht mehr für "alltagstauglich" oder programmierfreundlich oder lesefreundlich.
Im letzten Projekt habe ich zwar Rohdaten aus verschiedensten CSV-Dateien alle in einer einzigen Tabelle abgespeichert. (auch hier gab es einen Typ oder eben die Satzart).
Die interpretierten Daten (auseinandergefuselt) wurden aber in einer Struktur gespeichert, die alle möglichen Felder enthielt. Mal waren sie gefüllt, mal nicht.
Da sich bei einem SAP-System die darunterliegende Datenbank um das Wegoptimieren von Blanks, Nullen und sonstigen leeren Felder kümmert, und die Felder und Tabellen doch pysikalisch irgendwie- und -woanders abspeichert, als SAP uns glauben machen will, kann ich mir die Strukturen auch so machen, daß ich sie verstehe und debuggen oder im Klartext lesbar machen kann (se16...).
Aber hin und wieder ist man tatsächlich auf ein paar extrem individuelle und spezielle Dinge angewiesen und dann ist es gut, daß man weiß, wo man nachsehen muß (www. abapforum.com)
Gruß
babap
Seite 1 von 1
Vergleichbare Themen
9
Antw.
Antw.
3366
Views
Views
4
Antw.
Antw.
5312
Views
Views
Aus einer Tabelle Daten einer internen Tabelle filtern - Interne Tabelle ist eine Tabelle ohne Kopfzeile
von Sonne1234 » 09.12.2019 08:29 • Verfasst in ABAP® für Anfänger
von Sonne1234 » 09.12.2019 08:29 • Verfasst in ABAP® für Anfänger
5
Antw.
Antw.
1064
Views
Views
Zeilen von einer generischen Tabelle in eine interne Tabelle schreiben
von BecomingAnAbapGuru » 29.03.2022 10:27 • Verfasst in ABAP® für Anfänger
von BecomingAnAbapGuru » 29.03.2022 10:27 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
692
Views
Views
Werte von Mapping Tabelle in existierende Interne tabelle schreiben
von frankoline » 27.04.2023 10:35 • Verfasst in ABAP® für Anfänger
von frankoline » 27.04.2023 10:35 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
4708
Views
Views
Join über Tabelle trotz Pool/Cluster Tabelle
von em.tie » 04.12.2006 18:38 • Verfasst in ABAP® für Anfänger
von em.tie » 04.12.2006 18:38 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 20 Stunden von a-dead-trousers 5 / 371
vor 20 Stunden von a-dead-trousers 5 / 371
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 20 Stunden von a-dead-trousers 5 / 371
vor 20 Stunden von a-dead-trousers 5 / 371