Abfrage von großen Datenmengen

[dARKeAGLE]

Zitat von stahli:

Ich kann mir das Projekt gerade nicht ansehen, aber vielleicht gibt es ein Memoryleak o.ä. (dass z.B. dynamisch immer neue Verbindungen hinzugefügt werden oder so)?

EDIT @Christian:
Bist Du auf MySQL festgelegt? Sonst teste doch mal Firebird...

Nein auf MySQL bin ich nicht festgelegt. Habe auch die Treiber für Oracle und MSSQL.
Der eigentliche Fehler in der Produktivanwendung war auf Oracle, da sind des sogar 250 000 Datensätze.

Zitat von Sir Rufo:

da kommt mir doch ein Gedanke wegen der Größe ...
73 Felder mit VARCHAR(500)

Wenn die Datenbankkomponente jetzt die Felder in maximaler Größe und als Unicode in den Speicher holt dann sind das bei 20000 Zeilen:

Code:

73 {Felder} * 500 {CHAR} * 2 {Unicode} * 20000 {Zeilen} = 1460000000 Bytes
1,360GB

Die Größe der Felder mit VARCHAR(500) wurde frei gewählt, und ich sehe es nun auch ein, dass es totaler Blödsinn war.
Ich hoffe, man möge es mir verzeihen.

Zitat von Sir Rufo:

Diese redundaten (Adress-) Daten in der Buchungen Tabelle sind ja nun auch nicht wirklich hilfreich und haben in der Tabelle "buchungen" eigentlich nichts verloren.

Die Adressinformationen gehören in eine Belegtabelle und die Referenz auf den Beleg gehört in die Buchungstabelle.

Ich würde hier einfach mal ordentlich normalisieren und dann wieder zu diesem Problem zurückkommen - wahrscheinlich hat sich dieses Problem dann schon erledigt.

Alle Spalten als varchar(500) ist auch nicht gerade kreativ ...

Natürlich sollen die Daten nichts representieren, sondern nur für die Fülle von Daten stehen.



Gibt es bei einer TSQLQuery die Möglichkeit eine Master-Detail-Beziehung aufzubauen (Kann es leider nicht nachprüfen, da ich nur im Unternehmen eine Delphi-Version habe)?

Das mit dem Debugger werde ich gleich mal morgen ausprobieren.

Viele Grüße

[p80286]

Zitat von dARKeAGLE:

Der eigentliche Fehler in der Produktivanwendung war auf Oracle, da sind des sogar 250 000 Datensätze.

Da kann die Datenbank eigentlich nichts für.

vielleicht solltest Du mal ganz von Anfang an erzählen, um was es geht. Mir scheint hier wird nur an den Symptomen herum gemacht.
(nicht pers. gemeint)

Gruß
K-H

[dARKeAGLE]

Ist OK. Also es war einmal .... ne nur Spaß.


Es gibt zwei Anwendungen. Die Eine, ein ERP-System (Java), bereitet Daten für ein Report-Template auf. Anschließend wird die zweite Anwendung gestartet. Diese Anwendung ladet die Daten und erstellt ein PDF aus den Daten mit Hilfe des Templates. Aktuelle gibt es ca. 90 verschiedene Templates mit ca. 40 verschiedenen SQL-Abfragen. Von diesen Abfragen werden je nach Template 2-3 Abfragen benötigt. Ja, manche Templates haben das selbe Abfrage.


Da das Laden der SQL-Abfrage und das Zusammenbauen der Master-Detail-Beziehungen dynamisch geschieht, sollte es halt eine einheitliche Lösung sein.


Nun zum Problem:

Aktuell soll ein Report generiert werden, welcher im Detail ca. 250 000 Datensätze besitzt. Hierbei kommt es zur der Exception, dass nicht genügend Speicher vorhanden ist, also die Exception auf dem dieser Thread basiert. Die Datenbank an dem der Fehler auftrat war Oracle. Da ich den Fehler "schnell" reproduzieren wollte, habe ich kurzer Hand ein paar Testdaten geniert. Dadurch auch die Problematik mit Felder VARCHAR(500). Sollte quick'n'dirty sein.

Die Anzahl der Spalten im Produktivsystem liegen so bei 50 Stück mit unterschiedlichen Datentyp.


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


Vielleicht gibt es auch eine andere Lösung, solange es meine Master-Detail-Beziehung nicht gefährdet.

Hoffe ich habe alles erklärt und auch verständliche erklärt.
Falls noch einige Einzelheiten fehlen werde ich diese gerne nachreichen.


Vielen Dank im Voraus.

Viele Grüße

Christian

[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 von dARKeAGLE:

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

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 , weil ich seit 5 Tagen nichts anderes mache. Und keinen Millimeter voran komme.

Viele Grüße