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.