Viele Datensätze schnell aus Datei in Grid laden ...

[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".

[mjustin]

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.

[Bernhard Geyer]

[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?

[mjustin]

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 :)

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

[mjustin]

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.

[jfheins]

Könntest du nicht in der Nacht die Datenbank in ein XML File schreiben, und dann jeden morgen in jedem Client dieses XML File vom Server herunterladen und lokal in eine embedded DB einlesen?

Damit hättest du auf den Clients ein brauchbares DBMS und könntest die Daten trotzdem als XML herumschicken

[Bernhard Geyer]

Zitat von mjustin:

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.

Komischer Ansatz. Du willst dich um das QM "drücken" weil dieser auf DB's hohe Anforderungen stellt aber scheinbar bei "unrelationierter" Datenspeicherung (noch nichts) definiert hat und versuchst dann eine Lösung zu realisieren die aufwendiger ist, weniger Performant, Fehleranfälliger (Eine Exceldatei wird leichter Zerschossen werden wenn Clients abstürzen als ein DBMS) zu realisieren.