Hallo,

folgende Aufgabe würde ich gerne in Delphi 2009 Enterprise mit Standardkomponenten lösen (wozu ich in diesem Fall auch das QuantumGrid zähle, die in den Anwendungen bereits eingesetzt werden):

Ein Datenbestand mit ca. 100k Datensätzen zu jeweils 50 Feldern wird nachts von einem (Delphi-)Programm erzeugt. Diese Daten sollen von den FachanwenderInnen tagsüber dann in einer Delphi GUI Anwendung geöffnet, in einem QuantumGrid angezeigt und über Filterkriterien auf die gesuchten Daten eingeschränkt werden (z.B. von-bis Datum).

Ich würde es naiv mit einem TClientDataSet versuchen, das man als XML oder binär im Nachtjob abspeichert und dann in der Delphi GUI einliest. Aber ist das ausreichend schnell / resourcenfreundlich (es ist eine Terminalserverumgebung)? Oder überschreitet es die aktuellen ClientDataSet-Belastungsgrenzen zu sehr?

Das Ziel ist es vor allem durch den nächtlichen Lauf die Datenbank zu entlasten, und die Daten halbwegs schnell auf den Bildschirm zu bringen. Denkbar wäre, dass man die gewünschten Sätze bereits während des einlesens der Datei ausfiltert, oder nach dem Einlesen zuerst einen ClientDataSet Filterausdruck setzt, bevor die DataSource mit dem Grid verbunden wird. Auch das Cachen und Filtern auf einem Applikationsserver und Übertragung per DataSnap wäre möglich.

Also gesucht ist eine Lösung für diese Aufgabe, bei der t minimiert werden soll:

Grosse Anzahl Datensätze -> [Zeit t vergeht] -> Laden der Daten in eine Gridkomponente

Hallo,

100k Datensätzen zu jeweils 50 Feldern -> = 5 Mio. Werte
Wer will die denn auf einmal sehen

Die alle auf Verdacht zu laden und danach zu filtern, ist doof

Lasse den User vorher die Filter-Kriterien festlegen
und lade nur die Daten, die er tatsächlich haben will.
Oder lege selber fest, dass standardmäßig z.B. nur die Daten von gestern angezeigt werden (Datums-Filter)

Ausserdem würde ich bei der Anzeige selber nochmal die gerade anzuzeigenden Datenmengen prüfen
und bei Bedarf eine Meldung "zu viele Datensätze, bitte mit Filer einschränken" anzeigen.


Heiko

100k Datensätze mit 50 Spalten: Da dürfte jedes aktuell DBMS darüber lachen und die Daten sehr schnell zum Client liefern können. Vorrausgesetzt die HW ist für einen Server halbwegs aktuell und man hat bei der DB-Konfiguration nix falsch gemacht.

Auch die Darstellung sollte kein Problem sein - wenn man den in der Implementierung nix falsch macht.

Ich würde eher den Ansatz wählen das maximal (konfigurierbar) x Datensätze im Grid darstellbar sind und am Ende dann 'ne Meldung kommt "Bitt genauer einschränken".

Zitat von hoika:

Die alle auf Verdacht zu laden und danach zu filtern, ist doof ;)

Wie kann man sie denn filtern ohne sie zu laden :) ? Die grosse Datenmenge ist halt gegeben, sie müssen dann nur noch effizient abgelegt werden damit man sie ohne grosse Systemlast zu erzeugen einlesen kann. Notfalls als Exceldatei.

Zitat von mjustin:

Zitat von hoika:

Die alle auf Verdacht zu laden und danach zu filtern, ist doof

Wie kann man sie denn filtern ohne sie zu laden ?

Wozu hast du ein DMBS? Lass die DB filtern. Die kann das i.d.R. um Welten besser (schneller/performance-schonender)

Zitat von mjustin:

Die grosse Datenmenge ist halt gegeben,

Große Datenmenge schaut in 2010 anders auß. Wenn du was von 100 Mio./1Mrd. Datensätze gesprochen hättest dann könnten wir von größerer Datenmenge sprechen

Zitat von mjustin:

sie müssen dann nur noch effizient abgelegt werden damit man sie ohne grosse Systemlast zu erzeugen einlesen kann.

Hast du doch schon: Ein DBMS!

Zitat von Bernhard Geyer:

100k Datensätze mit 50 Spalten: Da dürfte jedes aktuell DBMS darüber lachen und die Daten sehr schnell zum Client liefern können. Vorrausgesetzt die HW ist für einen Server halbwegs aktuell und man hat bei der DB-Konfiguration nix falsch gemacht.

Auch die Darstellung sollte kein Problem sein - wenn man den in der Implementierung nix falsch macht.

Ich würde eher den Ansatz wählen das maximal (konfigurierbar) x Datensätze im Grid darstellbar sind und am Ende dann 'ne Meldung kommt "Bitt genauer einschränken".

Es gibt leider keine Ausgabetabelle in der Datenbank für die generierten Daten - wir müssen die Daten in einer separaten Datei halten (wegen Kundenvorgaben). Vielleicht ist Excel daher eine Alternative. Ich teste mal, wie lange es bei durchschnittlicher Last im System dauert, zehn Megabyte in ein ClientDataSet einzulesen (direkt aus der DB oder aus einer XML Datei). Die damit mögliche ExpressGrid Lösung wäre besser in die Anwendung integriert.

[QUOTE=mjustin;1041769]

Zitat von Bernhard Geyer:

Es gibt leider keine Ausgabetabelle in der Datenbank für die generierten Daten - wir müssen die Daten in einer separaten Datei halten (wegen Kundenvorgaben).

OK. Du darfst es in der ursprünglichen DB nicht halten. Aber wie wäre es dort eine weiter DB anzulegen und die Daten dort zu speichern?

Zitat von Bernhard Geyer:

OK. Du darfst es in der ursprünglichen DB nicht halten. Aber wie wäre es dort eine weiter DB anzulegen und die Daten dort zu speichern?

Technisch machbar, organisatorisch / QM-seitig leider nicht: Änderungen an den Metadaten der Datenbank (von denen es voraussichtlich viele geben wird) im Produktivsystem erfordern quasi eine vierwöchige Voranmeldung und dürfen nur zwischen Mitternacht und zwei Uhr durchgeführt werden. Sonst rollen Köpfe :)

Zitat von mjustin:

Technisch machbar, organisatorisch / QM-seitig leider nicht: Änderungen an den Metadaten der Datenbank (von denen es voraussichtlich viele geben wird) im Produktivsystem ...

Ich habe gesagt das eine neue DB angelegt wird und nicht in der aktuellen DB (Produktivssystem) die neuen Tabellen angelegt werden.

Zitat von Bernhard Geyer:

Zitat von mjustin:

Technisch machbar, organisatorisch / QM-seitig leider nicht: Änderungen an den Metadaten der Datenbank (von denen es voraussichtlich viele geben wird) im Produktivsystem ...

Ich habe gesagt das eine neue DB angelegt wird und nicht in der aktuellen DB (Produktivssystem) die neuen Tabellen angelegt werden.

Die neue DB wäre dann ebenfalls eine Produktivdatenbank und muss damit leider den gleichen strengen QM Regeln wie die bestehende folgen. Eine "Agile" Entwicklung ist in dieser Umgebung dann nicht möglich. Ein separates Testsystem mit weniger restriktiven Vorgaben müsste man ebenfalls irgendwann in Produktivbetrieb nehmen und dann sind alle Änderungen wieder aufwendig wg. QM.