Abfrage von großen Datenmengen

[Uwe Raabe]

Zitat von dARKeAGLE:

Jein. Ich nutze zwei TSimpleDataSet und eine TSQLConnection mit dem Devart Treiber MySQL Direct. Das TSimpleDataSet erbt ja vom TCustomClientDataSet.

Das Problem ist das TSimpleDataSet. Das ist, wie du schon bemerkt hast, ein TCustomClientDataSet. Somit hat es auch genau dieselben Einschränkungen. Es erspart dir lediglich ein SQLDataSet und einen DataSetProvider, die du andernfalls selbst verdrahten müsstest.

Das Simple-/ClientDataSet lädt stndardmäßig das komplette Abfrageergebnis in den Hauptspeicher und da knallt es natürlich ab einer gewissen Menge.

Du kannst also entweder deine Abfrage mit einer sinnvollen WHERE-Klausel verkleinern, was aber ohne Kenntnis möglicher Kriterien schwierig wird, oder (besser) du verzichtest auf das Grid und verwendest lediglich ein TSQLDataSet (das ist unidirektional und somit nicht in einem Grid darstellbar). Da sich aber wohl kaum jemand die ganzen 20000 Datensätze in dem Grid anschauen will, sollte das zu verschmerzen sein.

Wenn es nicht ohne das Grid geht, musst du feststellen, nach welchen Kriterien die Abfrage eingeschränkt werden kann (z.B. Jahr/Monat der Buchungen oder so). Dann zuerst das Kriterium eingeben und dann erst die Abfrage öffnen.

Vergiss alles bezüglich der Debug-Infos, das Problem ist die Menge der abgefragten Daten.

[p80286]

Zitat von Uwe Raabe:

...verwendest lediglich ein TSQLDataSet (das ist unidirektional und somit nicht in einem Grid darstellbar).

Warum sollte man es nicht in einem TStringgrid darstellen können?

Gruß
K-H

[Morphie]

Ihm geht dabei aber dann doch die Master / Detail Navigation flöten, oder?
Das Problem hätte er wie gesagt mit den gleichteuren MyDAC-Komponenten von DevArt nicht...

[Uwe Raabe]

Zitat von p80286:

Zitat von Uwe Raabe:

...verwendest lediglich ein TSQLDataSet (das ist unidirektional und somit nicht in einem Grid darstellbar).

Warum sollte man es nicht in einem TStringgrid darstellen können?

Gemeint war natürlich ein TDBGrid! Das kann mit unidirektionalen DataSets nichts anfangen.

Zitat von Bernhard Geyer:

Zitat von Uwe Raabe:

Das Simple-/ClientDataSet lädt stndardmäßig das komplette Abfrageergebnis in den Hauptspeicher und da knallt es natürlich ab einer gewissen Menge.

Bei MySQL ist das egal da es hier keine serverseitigen Curser gibt.

Das hat damit nichts zu tun. Das ClientDataSet schickt eine Anfrage an den DataSetProvider, der diese wiederum an das SQLDataSet weitergibt. Dieses liefert eine Ergebnismenge, die der DataSetProvider an das ClientDataSet weitergibt. Intern wird dabei das MyBase-Format (Midas) zum Transport verwendet, bei dem die gesamte Datenmenge im Hauptspeicher vorliegt.

Zitat von Bernhard Geyer:

20.000 Datensätze sollten aber (wenn keine größeren Blobs) beteiligt sind selbst in einem 32-Bit Prozess noch keine Probleme darstellen.

Prinzipiell ist das richtig, aber wenn so mit den Feldgrößen geast wird. Wie Sir Rufo treffend bemerkt, hat die Buchungstabelle 73 Felder vom Typ VarChar(500). Das sind selbst bei AnsiChar ca. 37000 Byte pro Record. Bei 20000 Records kommen wir da schon auf fast 750MB. Wenn die intern beim Transport auch nur einmal by-value kopiert oder in einen Memorystream geschrieben wird, sind wir schon bei 1,5 GB.

[Bernhard Geyer]

Zitat von Uwe Raabe:

Prinzipiell ist das richtig, aber wenn so mit den Feldgrößen geast wird. Wie Sir Rufo treffend bemerkt, hat die Buchungstabelle 73 Felder vom Typ VarChar(500). Das sind selbst bei AnsiChar ca. 37000 Byte pro Record. Bei 20000 Records kommen wir da schon auf fast 750MB. Wenn die intern beim Transport auch nur einmal by-value kopiert oder in einen Memorystream geschrieben wird, sind wir schon bei 1,5 GB.

Das wollte ich auch schon ausrechnen.
Seine Testdaten zeigen aber keine annähernde füllung dieser jeweils 500 Byte (Backup ist insgesamt ca. 500 MB groß) so das ich denke das diese 20.000 Datensätze kein 1,5 GB (wenn keine Fehler vorhanden sind) füllen würden.

[p80286]

Es soll ja auch schon vorgekommen sein das varchar500 als 500 Blanks über die Leitung gehen, intern aber wirklich nur ein Blank groß sind.

Vielleicht hilft da der Debugger weiter?

Gruß
K-H

[stahli]

Es kann natürlich sein, dass die Datenbank (File) leere Einträge packt, der Treiber die DataSet-VarChar-Felder aber immer mit Leerzeichen auffüllt bzw. einfach maximal viel Speicherplatz reserviert.

[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

[stahli]

(Bezugnahme auf Uwe´s Beitrag)
... oder eine Alternative zum DBExpress wählen.

Ich kenne mich im Detail zwar nicht aus und WILL NICHT die BDE empfehlen, aber unter BDE wurden nur die Datensätze in das DBGrid geholt, die auch dargestellt wurden.

Ich weiß nicht, welche Möglichkeiten sich da aktuell anbieten.

Bei DBExpress zu bleiben ist m.E. vor allem sinnvoll, wenn man eine spätere Skalierung auf DataSnap für möglich hält. So ließe sich das Projekt (m.E.) am einfachsten auf DataSnap umstellen.
Ist das ausgeschlossen und sind große bidirektionale Datenmengen im Spiel ist BDExpress möglichweise nicht erste Wahl.

(meine aktuelle Einschätzung)