Abfrage von großen Datenmengen

[jobo]

Ohne ins Detail zu gehen. In einem Client Server System dient der Server zur Aufbereitung der Daten, der CLient zur Pflege und Darstellung.
250000 Detaildatensätze schaut sich niemand an. Naheliegend, dass sie mit dem Reportsystem das Du verlinkt hast irgendwie weiterverarbeitet werden (sprich eingedampft). Da es um Reporting geht, scheidet eine einfache Beschränkung der Datensatzanzah aus. Ich kenn das jetzt nicht konkret, aber Du kannst die Hersteller ja mal anmailen, wie ihre Reportkomponenten mit Datenmengen > 100000 Records umgehen...

Wenn Du das ganze Verfahren nicht ändern kannst, empfehle ich einen genaueren Blick auf die Detaildaten. Vielleicht kann man hier mit Teilaggregationen arbeiten, Spalten weglassen usw. und so irgendwie auf Datenmengen kommen, die clientseitig verarbeitet werden können.

[Uwe Raabe]

Zitat:

Zitat von dARKeAGLE (Beitrag 1197521)

Da ich den Reportbuilder von Digital Methaphors verwende benötige ich ein Dataset (siehe http://www.digital-metaphors.com:8080/Data_Access).

Die Aufgabe sollte mit zwei SQLDataSet, die über eine DataSource in eine Master-Detail-Beziehung gebracht werden, zu lösen sein.

[dARKeAGLE]

Zitat:

Zitat von jobo (Beitrag 1197529)

Ohne ins Detail zu gehen. In einem Client Server System dient der Server zur Aufbereitung der Daten, der CLient zur Pflege und Darstellung.
250000 Detaildatensätze schaut sich niemand an. Naheliegend, dass sie mit dem Reportsystem das Du verlinkt hast irgendwie weiterverarbeitet werden (sprich eingedampft). Da es um Reporting geht, scheidet eine einfache Beschränkung der Datensatzanzah aus. Ich kenn das jetzt nicht konkret, aber Du kannst die Hersteller ja mal anmailen, wie ihre Reportkomponenten mit Datenmengen > 100000 Records umgehen...

Wenn Du das ganze Verfahren nicht ändern kannst, empfehle ich einen genaueren Blick auf die Detaildaten. Vielleicht kann man hier mit Teilaggregationen arbeiten, Spalten weglassen usw. und so irgendwie auf Datenmengen kommen, die clientseitig verarbeitet werden können.

Der Sinn hinter diesen großen Datenmengen erschließt sich mir auch nicht. Leider habe ich keinen Einfluss auf die Daten und muss mit den vorhandenen Arbeiten.

Ich glaube, dass mit den TSQLDataSet funktioniert auch nicht, da Sie unidirektional sind, aber der Reportbuilder bi-direktionale DataSet benötigt.

Zitat:

The reports and datapipelines use dataset bookmarking. Make sure the dataset can support bi-directional navigation.

Siehe hier:
http://www.digital-metaphors.com:808..._Access_Errors

Vielleicht habe ich es auch falsch verstanden.
Gibt es sonst noch eine Möglichkeit, das Caching von ClientDataSets in eine Datei auszulagern?

Viele Grüße

Christian

[Furtbichler]

Ich weiß, das Nachbohren nervt: Werden wirklich 250.000 Datensätze im Report dargestellt und muss das so sein? "Äh, die wollen das so" ist zunächst keine Antwort. Man kann ja auch mal anmerken, das es Probleme bereitet.

Wenn JA (weil z.B. Niemand nachdenken will, warum, und Du den Rotz ausbaden musst), dann geht es ja eigentlich nur um den Auftrag, diesen Mumpitz zu produzieren. Hier sollte man sich überlegen, ob man nicht anderweitig, also ohne diesen Reportbuilder, zum Ziel kommt. Das geht z.B. über Exportfunktionen des RDBMS: Die Daten werden also vom DB-Server direkt in eine Datei geschrieben (z.B. EXCEL). Dann muss sich der Endanwender eben rumschlagen, wie er die 250k-Zeilen-Datei in seinen Rechner bekommt.

Andererseits kenne ich keinen Reportbuilder (und auch keinen Anwendungsfall), bei dem man durch diese Datenmassen scrollen muss. Die Vorgabe, beliebig viele Daten anzeigen zu können, ergibt sich meistens aus der Tatsache, das die Anwendung bestimmte Funktionen nicht bietet, die Anwender jedoch bestimmte Probleme lösen müssen.

Ich habe gerade konkret solche Fälle, bei denen es um die Massenkorrektur von Daten geht.
Die Daten müssen auf Eingabefehler oder Inkonsistenzen geprüft werden. Das kann die Anwendung nicht, also haben sich die Sachbearbeiter den Trick ausgedacht: Daten laden, als XLS-exportieren, in EXCEL öffnen und filtern/sortieren, um Probleme zu erkennen, dort korrigieren und als CSV speichern. Dann wird aus der CSV-Datei über RegEx eine Datei mit 100.000 UPDATE-Befehlen erstellt, die dann zum DB-Server geschickt wird. Toll, gell?

Das Problem ist also hier z.B. das Fehlen einer direkten Exportfunktion, ohne Umweg über das Grid oder gleich das Richtige Datenvalidierungs- und korrekturtool.

Deshalb ist es so immens wichtig, den genauen Grund zu erfahren, wieso irgendwo 250k Datensätze aufgelistet werden müssen. Na, und wenn darauf bestanden wird, durch 250k Datensätze zu scrollen, dann baut man eben einen Pagingmechanismus, das sollte doch wohl gehen.

[dARKeAGLE]

Hallo,

nachbohren nervt nicht, ist manchmal auch sehr wichtig.:)


Ich habe mir mal die Daten, genau angeschaut. Im Master steht ein Datensatz, welcher nur Überschriften enthält. Im Detail sieht es noch schlimmer aus. Hier werden alle Datensätze kombiniert zusammengefasst. Dies bedeutet die 250 000 Datensätze setzen sie z.B. wie folgt zusammen:

250 000 Buchungen = (Mandant A * 200 Buchungen) + (Mandant B * 300 Buchungen) + (Mandant C * 300 Buchungen) + ... + ...

Aufgrund dessen habe ich mal genauer nachgefragt, wie man so eine Datenhaltung rechtfertigt :)
Die Antwort:
Ist das es mehrere Ausgaben (Listen, Tabellenkalkulation und noch 5 weitere) im System gibt und daher die Daten so abgelegt werden. Der Reportbuilder soll nur die ERP-Software im neuen Jahrtausend willkommen heißen, damit die Auswertungen gleich an die Mandanten in schöner Form geschickt werden können, also als Brief oder Email.
Gerade mit den 250 000 Datensätzen wären das ca. 3-15 Seiten pro Mandant, die geniert werden sollen. Was ja wieder human ist und sich auch jemand durchliest.

Dennoch wird die Master-Detail-Beziehung benötigt, weil es andere Reports gibt, die wirklich nicht nur einen Master-Datensätz haben, sondern das Prinzip der Master-Detail-Beziehungen folgen.

Im Moment könnte ich nur :kotz:, weil ich seit 5 Tagen nichts anderes mache. Und keinen Millimeter voran komme.

Viele Grüße

[Morphie]

Dann frag ich auch noch mal nach, warum du nicht die MyDAC-Komponenten von DevArt nimmst? damit ist es ein Kinderspiel und es gibt auch keine Fehler. (gerade mit deinem Projekt getestet)

MyConnection1:
Username, Password, Server, Port und Database eintragen
LoginPrompt = false
Connected = true

MyQuery1:
SQL = SELECT * FROM MANDANT;
Connection = MyConnection1
Active = true

MyDataSource1:
Dataset = MyQuery1

dbgrdMaster:
DataSource = MyDataSource1

MyQuery2:
SQL = SELECT * FROM BUCHUNGEN;
MasterSource = MyDataSource1
MasterFields = Mandant
DetailFields = Mandant
Connection = MyConnection1
Active = true

MyDataSource2:
DataSet = MyQuery2

dbgrdDetail:
DataSource = MyDataSource2

[dARKeAGLE]

Sieht ja nicht schlecht aus.

Bin schon seit gestern am überlegen. Haben halt erst vor 4 Monaten die gesamten DBExpress Treiber für MySQL, Oracle und SQL Server gekauft, daher wird mein Chef nicht unbedingt erfreut sein, wenn ich schon wieder was will. Aber das ist ein anderes Problem.

Daher meine Frage:

Reicht auch der Universal Data Access Components oder ist es besser wieder für jede Datenbank es einzelt zu kaufen? Oder soll ich für die Frage einen neuen Thread stellen?

Viele Grüße

Christian

[Morphie]

Sollte eigentlich mit denen auch funktionieren... Man kann sich aber auch Trial-Versionen herunterladen und testen... Das würde ich mal vorschlagen ;-)

[dARKeAGLE]

Zitat:

Zitat von Morphie (Beitrag 1197583)

Sollte eigentlich mit denen auch funktionieren... Man kann sich aber auch Trial-Versionen herunterladen und testen... Das würde ich mal vorschlagen ;-)

Habe mir mal das Universal Gedöhns geladen. Es funktioniert sogar mit der kaputten Datenhaltung (VARCHAR(500)) und 500 000 Datensätzen (Mandant "!04") kommt er nicht mal über 1GB Ram Auslastung :) so kann ich des mein Chef gut verkaufen.

Viele Dank nochmal an alle die mir geholfen haben.

Viele Grüße

Christian