Master-Detail mit many-to-many Relation

[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 von 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.

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

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?

[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.