Master-Detail mit many-to-many Relation

[WM_CLOSE]

Zu langsam, aber vielleicht hilft es ja.

Dann mach doch noch statt dem WHERE Filter noch nen Join. Dann hast du alles was du brauchst in einem Query.

Autordaten Verweis(nicht sichtbar) Buchdaten
Schumann 1 1 Delphi für Kids
Schumann 1 2 Spieleprog. m. C++
Spolwing 2 3 Class in a Box Delphi
Doberenz 3 4 Borland Delphi 7...
Gewinnus 4 4 Borland Delphi 7...

Nun tue für jede Zeile:
-Suche den Node mit der Id des Autors
-Speichere ihn in der Variable Node
-Solltest du ihn nicht gefunden haben
-Erstelle einen neuen Node mit den Autordaten und speichere ihn in der Variablen Node
-Trage nun unter dem Node aus Variable Node
einen neuen Node mit den Bücherdaten ein

[Stevie]

Manchmal frag ich mich hier echt, wozu man irgendwelche Vorgaben macht und auch noch erwähnt, dass diese unveränderlich sind, wenn manche dann andauernd mit Alternativen um die Ecke kommen. Ich kenne die Alternativen, es über einen Join in eine Datenmenge zu bekommen, und diese wieder auseinander zu nehmen. Ist aber hier nicht gefragt. :wall:

@FredlFesl: Ja, das Prinzip des Pivot Grids kommt meinem Vorhaben in etwa nahe, ist mir aber zu starr an diese spezielle Komponente gebunden. Ich vermute auch, dass man im PivotGrid auch nur eine Datenmenge angeben kann, die dann so aufbereitet wird oder? Mir geht es wirklich darum die n-zu-n Beziehung (die ja eigentlich 2mal eine 1-zu-n Beziehung ist) so aufzulösen, dass ebend nicht diese extra Ebene entsteht, die durch die 2 1-zu-n Beziehungen entsteht.

[jobo]

Warum regst Du Dich so über "SQL-Antworten" auf, wenn Du Deine Anfrage unter "Datenbank" postest?
und ich frage mich außerdem, was eigentlich Deine Frage ist.

Meines Wissens gibt es Komponenten, die eine beliebige Datenmenge beliebig gruppieren können. Bei normalisierten Daten kann das sinnvollerweise nur auf Attributen erfolgen, die eine Art Klassifizierung darstellen, also irgendwie mehrfach auftauchen. Klar, ohne "mehrfach" keine Gruppierung.
Stichwort wäre jedoch "normalisiert" bzw denormalisiert. Hast Du mehrere Mengen, 2, 3, 4 .. könntest du den umgekehrten Weg gehen, die Mengen alle zusammenbringen, also denormalisieren und dann auf dem großen Datenwürfel nach Herzenslust gruppieren (Stichwort Pivot ist ja schon gefallen). Das bringt natürlich die bekannten Probleme mit sich, wenn die Datenmengen groß werden. Und das willst Du ja anscheinend auch nicht.

Sollen die Mengen disjunkt bleiben, könnte man etwa folgendes Standardvorgehen wählen:
Gruppierungsmenge 1 festlegen
Verknüpfungsmenge 2 festlegen
Detailmenge 3 festlegen

1 wird nach Gruppierungsattribut sortiert,
Menge 2 wird wie 1 plus gewünschter Detailordnung (Hier schon ggF weitere Unter Gruppierung berücksichtigen)
3 wird nach Detailordnung von 2 sortiert (evtl auch egal, muss wahrscheinlich sowieso located werden)

Für alle 3 Mengen die Verknüpfungsattribute definieren

Dann Treeview oder Liste aufbauen:
Erste Eben über Menge 1 füllen (komplett)
Dann je nach Bedarf und Aufwand ("onexpand" oder ebenfalls alles ) Menge 2 und 3 durchsteppen bzw. "locaten" und entsprechende Nodes an Ebene 1 anhängen.

Bei disjunkten Basismengen taugt das Verfahren allerdings nur zur Herstellung der Hierarchie, die tatsächlich in den (mglw. sauber normalisierten) Basismengen abgebildet ist. Gruppierung über beliebige Klassenattribute wie oben genannt funktioniert so nicht ohne weiteres (Stichwort doppelte Elemente/Mehrfachnennung), zumindest habe ich spontan das Gefühl, dass das noch etwas aufwändiger wäre.

[Stevie]

Zitat:

Zitat von jobo (Beitrag 1116920)

Warum regst Du Dich so über "SQL-Antworten" auf, wenn Du Deine Anfrage unter "Datenbank" postest?
und ich frage mich außerdem, was eigentlich Deine Frage ist.

Ich war der Ansicht, die Vorgaben im Ausgangspost schon genannt zu haben. Generell habe ich nichts gegen die Nennung von Alternativlösungen. In dem konkreten Fall war aber nach einer konkreten Vorgehensweise gefragt. Für mich hat auch nicht alles, was Datenbank ist, mit SQL zu tun. Naja, egal, ich blende die mich nicht weiterbringenden aber gut gemeinten Antworten einfach im Geiste aus :-D

Was du schreibst, klingt in etwas nach meinem Ansatz, den ich mir bisher auch überlegt habe. Im Falle von großen Datenmengen steht auch einer vorherigen Filterung nichts im Wege (z.B. über SQL). Scheint auch mein bisheriges Problem zu lösen, wenn ich auf höheren Ebenen Gruppierungen habe die erst auf eine Datenmenge weiter unten in der Hierarchie Anwendungen finden.

Noch ein Tip, ob ich mit temporären Filtern auf die Datasets arbeiten sollte, oder immer ungefiltert mit z.B. Locate arbeiten sollte?

[FredlFesl]

Zitat:

Zitat von Stevie (Beitrag 1116606)

Ich vermute auch, dass man im PivotGrid auch nur eine Datenmenge angeben kann

Ja, das ist das Wesen eines Datastore/Datawarehouse. Millionen/Milliarden von Daten lassen sich nicht mehr performant in normalisierten Tabellen halten, die verknüpft werden. Ein Datastore besteht aus einer Tabelle, bei denen vielleicht noch einzelne Dimensionen mit einer Kindtabelle verknüpft sind (z.B. Zeitstempel). Diese Kindtabellen sind aber allesamt im Speicher der Datamining-Anwendung, sodaß die Verknüpfung in-Memory stattfindet.

Um also deine Frage zu beantworten: Ich würde die n:m-Beziehung per SQL-JOIN auflösen, mir eine einzige Tabelle einlesen und die Gruppierung über ein Pivot-Grid oder etwas selbstgestricktes realisieren. Das Selbstgestrickte hat den Vorteil, auf die Besonderheiten deiner Datenmenge bzw. Anwendung besser eingehen zu können. Ein Pivot-Grid hat den Vorteil, das es schon fix-und-fertig ist... Fast-Report hat z.B. eine Pivot-Komponente, und der gute alte TDescision-Cube ist mit wenigen Handgriffen von der BDE befreit. Ob das allerdings genau das ist... frage ich mich auch gerade... Du willst ja gar nicht mit den Aggregatmöglichkeiten herumspielen... oder doch?

Man muss die Daten im Übrigen nicht komplett im Speicher halten. Wenn man sich auf die 'abstrakte' Sicht auf die Daten festgelegt hat (das ist ja das, wonach du u.a. suchst), kann man mit Cache, "SELECT DISTINCT" etc. durchaus eine Pufferungsebe implementieren..

Desweiteren sind auch die Gruppierungsmöglichkeiten von nativem SQL nicht zu unterschätzen. Das kommt allerdings erst dann zum tragen, wenn viele Datensätze einer Tabelle stark verdichtet werden müssen.

Und was die performante Darstellung anbelangt: Ich habe mir angewöhnt, die Daten schnellstmöglich aus dem TDataset herauszulösen und in Hashmaps oder Tries zu stopfen. Erst damit ist eine verzögerungsfreie Darstellung/Umgruppierung möglich.

[jobo]

Filter oder Locate hängt m.E. stark vom Datenaufkommen, clientseitiger oder serverseitiger Datenmenge, etc ab.

Außerdem gibt es Handlingprobleme, wenn ein Filter in der Detailmenge steckt und die 1. (oder höhere) Gruppierungsebene nichts von dem (Detail-)Filter weiß. Das ließe sich nur umgehen, wenn man eine Gruppe komplett füllt (oder eben nicht, wenn Details fehlen), was aber bei großen Datenmengen wieder problematisch sein kann.
Bei einer Clientdatenmenge, dürfte Filter oder Locate nicht so einen Unterschied machen, wenn sie einmal aufgebaut ist, ist ja dann eh alles "Kopfrechnen".
Ein SQL Filter bietet aber mehr Freiheiten und macht große Mengen beherrschbarer.

Auf die Thematik "Datawarehouse" und die Vor/Nachteile ist Fredlfesl ja schon eingegangen. Ein aggregierter Datenwürfel bietet in der Handhabung sicher deutlich mehr Komfort, als separate Mengen umzuschubsen. (Wenn er denn mal aufgebaut ist)

Am elegantesten scheint mir ein (virtueller) Würfel in der DB zu sein, besonders bei großen Datenmengen. Aber das ist ja nicht Dein Thema, da musst Du notfalls filtern, was dich interessiert. ;)