Domino 9 und frühere Versionen > Entwicklung

Größere Datenimport

(1/3) > >>

Rob Green:
ich habe ca. 150.000 - 200.000 CSV basierende Textzeilen in Notes zu importieren. Nun möchte ich aber die späteren Verarbeitungsprozesse aufgrund des umfangreichen Ansichtsindex reduzieren.

Hierzu habe ich folgende Überlegung:
jede Textzeile beinhaltet mehrere Datenspalpten, Semikolon getrennt. Dabei ist jede Textzeile zu Beginn durch eine Kontonummer gekennzeichnet, die n-mal in den CSV Dateien vorkommen kann.

Wenn ich nun in einer For bzw. While Schleife die Zeilen textweise einlese, checke ich, ob die Kontonummer als Notesdocument bereits vorhanden ist. Wenn nicht, erzeuge ich ein neues Doc mit dieser Kontonummern, wenn ja, schreibe ich die n-te Zeile in ein Textfeld des bereits vorhandenen Kontonummern Documents. Damit reduziere ich die Anzahl der Dokumente für spätere Verarbeitungen erheblich, indem ich eben die Informationen bereits beim Import gruppiere.

Ist dieser Ansatz ok oder sollte ich versuchen zunächst alles in einzelne Arrays virtuell einzulesen (wobei ich mir beim letzteren nicht im klaren bin, ob ich dynamisch beliebig viele Arrays in Anzahl der unterschiedlichen Kontonummern erstellen kann, um damit zum Schluß Docs zu erstellen)?

Ich weiß, ich könnte es viel einfacher in Access haben, aber ich wollte es eben mit Notes komplett machen.

Performance:
der Ansatz ist ok

besser ist du hast die Kontonummer sortiert, dann erzeugst du nur am Anfang einer neuen Kto ein dok und hälst es offen bis eine andere Kto auftaucht. Das Suchen in einer view ab 40k doks ist eine Geduldsarbeit, auch wenn es Lotus Skript ist.


- in so einem Fall gebe ich meinem Datenlieferanten den Auftrag wie er mir die Daten liefern soll.
- wenn du öfters über 100k Zeilen importierst empfehle ich die C-API - das ist dann wirklich der Turbo - vor allem wenn der Server produktiv ist ist die C-API um Längen besser.


cu

Rob Green:
prinzipiell wede ich die gelieferten Daten leider nie in einem sortierten File bekommen, sondern stets 12 Stück, da die Daten automatisiert durch bestimmte HOST Läufe einmal monatlich in einem CSV File generiert werden, die aufgrund der Vorhaltedauer von 30 Tagen wieder vom HOST entfernt werden (die Files werden per FTP woanders abgelegt).

Im ersten Schritt werde ich wohl dieses oben genannte Verfahren wählen - auch wenn es unsortiert ist - und in einem späteren Step, werde ich versuchen, entweder ein Runtime Modul von Access anzusprechen, das aus der Notes DB abgelöst wird, dann die CSV Daten reinschaufelt und per ODBC mit Notes kommuniziert (um alles in einer Notes DB vorzuhalten, damit neuere Installation auf anderen Server/Client Plätzen einfacher gestaltet sind..bin mir aber leider nicht ganz im klaren, ob ich dabei auf VBzurückgreufen soll oder COM) ODER in einem zusätzlichen Nachfolgeschritt versuchen, in der Tat über C-API zu arbeiten, damit der Einlesevorgang per se beschleunigt wird, jedoch weiterhin die Daten in Access eingelesen werden, um gruppiert zu werden. Habe deswegen Access als Runtime Modul im Kopf, da ich in einem anderen Fall aufgrund HOST Auswertungen Daten in Access anhand Kundenbetreuerschlüsseln gruppiere, daraus variabel Exceldateien pro Empfänger erstelle und dann als Serienmail an die Adressaten versende. Hatte damals aber das Vorgehen aufgesplittet: erst Daten in Access per Fieldmapping eingelesen, dann Excel Tempalte Dateien über VB aus Access heraus generiert und diese dann per Script in Notesdocs angehangen. Ist für normale User natürlich nicht gangbar, jedenStep in separaten Programmen vorzunehmen.

Das Dumme ist an allen Lösungen, daß das Gebilde ca. 15 Jahre laufen soll...*gulp*...wer weiß schon in 15 Jahren, obs überhaupt noch PC´s mit Lotus Notes als Software gibt...roflmao...mir scheint es fast, als müsse ich mich doch mal mit XML befassen, evtl. bekomme ich die HOST Leute dazu, mir die Daten im XML Format zu liefern. Fühlt sich irgendwie zukunftsträchtiger an.

Danke für die Bestätigung, Performance.

eknori:
Aslo ich kann mich Performance nur anschlie0en: Am Besten die Dokumente nach Kto sortieren. Dann haben wir nur noch ein klassisches Problem der Datenverarbeitung vor uns: den bei allen Azubis so beliebten "Gruppenwechsel". = "Erzeuge ein Doc anhand der Kontonummer und schreibe solange Daten in dieses Dok, bis sich die Kto.-Nr ändert."

ein GetDocumentByKey über die Kontonummer dürfte bei ungeortneten Daten aber auch ganz gut machen, da sich ja die anzahl der Dokumente drastisch reduziert.

Ein anderer Ansatz wäre aber auch, wie es in der klassischen Datenverarbeitung üblich war, eine sog. "Schnelldrehertabelle"

Dabei geht man folgendermaßen vor.

Die Tabelle ist ein Array mit sagen wir einmal dim 10.

Der erste Datensatz wird gelesen und ein Dok anhand der Kto.-Nr erzeugt ; das Dol bleibt aber im Speicher
Nächster Datensatz lesen und anhand der Tabellöe prüfen, ob es bereits ein Dok mit der Nr. gibt.
Wenn nicht, neues Dok erzeugen; wenn ja, Daten in geöffnetes Dok schreiben.
Das geht dann solange, bis das Arrax voll ist, also 10 geöffnete Dokumente da sind.
Kommt jetzt ein Dokument, das in der Tabelle nicht vorhanden ist, wird das Dokument, das zu diesem Zeitpunkt die wenigsten "Treffer" hatte geschlossen.

Damit erhälst du dann eine Art Top 10 der Kto.-Nr.  und du hast die Dokumente, die vile treffer haben immer im Speicher.

Ist ein Dok nicht in der Tabelle, muß natürlich auch gesucht werden, ob das Dok nicht schon gespeichert wurde.

Hab ich mal als Prüfungsaufgabe bei der IHK Essen 1995 gestellt ( COBOL ); spannende Ergebnisse  ;D ;D ;D

Ulrich

Doc Torte:
anderer Vorschlag, Du legst das Doc mit der esten Kontonummer an, erstellst Die nebenbei eine Stringlist, als Listenelement die Kontonummer und als Listeneintrag die DocID der erstellten Docs,
dann kommt die nächste Kontonummer, da fragst Du ab, ob diese schon verarbeitet wurde (IsElement) in der Liste, wenn nein, neuer Listeneintrag Kontonummer/DocID, wenn schoneinmal die Kontonummer gelaufen ist, holst Du Dir das erstellte Doc über die DocID in der Tabelle und das als Schleife läuft auch schneller als in einer Ansicht zu suchen ...

ich verarbeite alle Größeren Datenmengen in Listen, somal man mit Stringlisten keine Größenbeschränkung hat.

Navigation

[0] Themen-Index

[#] Nächste Seite