Dateiverarbeitung in Java

[Gast Stefan]

Hallo,
ich möchte über Java eine CSV-Datei verarbeiten und daraus Datenbank-Befehle generieren (INSERT Statements). Ich sehe hier zwei Möglichkeiten. Entweder die Datei wird direkt als Datei Zeile für Zeile ausgelesen oder die Datei wird in eine Datenbank-Tabelle überführt, und das Coding ließt dann die Tabelle aus.
Habt ihr noch andere Ideen bzw. wisst welche von meinen beiden angedachten Varianten performanter ist?

[thereisnospace]

Die Datei in das Programm einlesen und dann über den Datenbankcontroller die Insert-Statements durchführen. Das geht mit mit der richtigen Bibliothek ziemlich fix und ist performant. (http://opencsv.sourceforge.net/)

Die Datei erst in eine Datenbank-Tabelle zu überführen, um sie dann wieder auszulesen, um sie dann für Datenbank-Befehle zu benutzen wäre ja nicht so performant oder? Oder habe ich da etwas falsch verstanden?

Bearbeitet 2. September 2016 von Gottlike
Link hinzugefügt

[Whiz-zarD]

Ein Hinweis:
Ein Insert-Befehl pro Datensatz ist extrem inperformant. Bei 10 Datensätzen ist es noch kein Problem, aber wenn es über 1.000 sind, dann kann es schon einige Zeit dauern, bis alles in die Tabelle geladen wurde. Das ist auch einer der Gründe, warum sich Microsofts O/R-Mapper Entity Framework sich nie richtig durchsetzen konnte, denn dort wurde tatsächlich jeder Insert einzeln ausgeführt. Inzwischen hat Microsoft das Entity Framework komplett neu entwickelt, um diese Fehler zu korrigieren.

Je nach dem wie groß das Projekt wird, würde ich ein O/R-Mapper empfehlen, der das dann übernimmt. Dann erzeugt man per Java-Code lediglich nur eine Liste von den Geschäftsobjekten aus der CSV-Datei (Deserialisierung) und sagt dann dem O/R-Mapper, er solle die Liste in die Datenbank einspielen. In Java dominiert der O/R-Mapper Hibernate. Selber SQL-Statements generieren würde ich eigentlich nicht, da man dann sich abhängig von der Datenbank macht und vielleicht möchte man sie irgendwann wechseln. Jede Datenbank hat so seine Eigenheiten und ein O/R-Mapper kapselt diese Eigenheiten, sodass man sich darüber kaum Gedanken mehr machen muss. 

Aber ich weiß nicht, was du vorhast oder welchen Wissensstand du besitzt aber wenn für dich der O/R-Mapper zu viel Overhead bedeutet, dann generiere doch einfach per Code ein Insert-Statement und schicke es zur Datenbank. Eine CSV-Datei auslesen ist ja nicht schwer.

[mqr]

Hallo Community,

vor 16 Stunden schrieb Whiz-zarD:

Ein Insert-Befehl pro Datensatz ist extrem inperformant.

Diese Sichtweise hört sich für mich so an, als ob bei jedem neuen Datensatz wieder die komplette Tabelle durchgegangen werden muss(?), bis das Ende erreicht ist und ein neuer Datensatz angefügt werden kann. Besser (performanter) wäre es natürlich gleich zum Ende zu springen und den neuen Datensatz zu platzieren. Bzw. ein Array zusammen zu bauen und es später zur Datenbank um zu benennen.

Wenn man sich die Datenbank jetzt selbst baut, denke ich mir: Man greift sich die CSV, holt sich die erste Zeile (Datensatz), separiert das bis zum nächsten Komma und speichert jedes Datum von seinem Datensatz (Evt. im "Arbeitsspeicher" bis der komplette Datensatz für den Insert-Befehl vorbereitet ist). Natürlich merkt man sich die Datensatznummer und geht eins weiter, so fort. Ich frag mich was da jetzt performanter zu machen ist und wie man das so "versauen" kann, dass der Datenimport von der eigenen Datenbank in eine neue, Zukunftsweisendere nicht klappt. Ich wüsste nicht was man da besser machen könnte. Ein Zwischenlagern in einer neuen Tabelle ist nur dann sinnvoll(nötig), wenn mann mit der Import-Funktion arbeiten muss.

Grüße

Micha

Bearbeitet 3. September 2016 von mqr
Insert ohne "n" geht gar nicht!

[Whiz-zarD]

vor 2 Stunden schrieb mqr:

Diese Sichtweise hört sich für mich so an, als ob bei jedem neuen Datensatz wieder die komplette Tabelle durchgegangen werden muss(?), bis das Ende erreicht ist und ein neuer Datensatz angefügt werden kann. Besser (performanter) wäre es natürlich gleich zum Ende zu springen und den neuen Datensatz zu platzieren. Bzw. ein Array zusammen zu bauen und es später zur Datenbank um zu benennen.

Das tatsächliche Einfügen ist weniger das Problem, wobei hier die Festplatte der Flaschenhals ist, wenn es sich nicht um eine In-Memory-Datenbank handelt. Das eigentliche Problem wird gerne viel vielen Übersehen: Das Parsen.

Es ist zwar für uns nur ein String, aber für ein DBMS harte Arbeit. Das Statement muss geparst werden, damit das DBMS weiß was der Nutzer überhaupt will. Danach wird ein Ablaufplan erstellt, wie man das Statement am performantesten abarbeiten kann. Dabei werden dann u.a. Statistiken der Tabellen und Indizes gelesen und dann wird der Plan abgearbeitet. Bis es zu er tatsächlichen Abarbeitung kommt, wird sehr viel Zeit verbraten und jetzt stelle dir mal vor, das muss das DBMS bei jedem der Tausend Insert-Befehle ausführen. Da wird Tausend Mal immer das selbe gemacht. 

Gängige DBMS-Systeme können dieses Problem ein wenig kompensieren, indem sie ein Query-Cache implementiert haben, mit dem überprüft werden kann, ob die Query, die gerade geparst werden soll, nicht schon vorher geparst wurde. Das klappt mal mehr, mal weniger gut.

Man sollte sich also im Klaren sein, dass ein DBMS auch kein Hexenwerk ist und nicht alles in Echtzeit schafft. Man sollte sich schon damit befassen, wie ein DBMS arbeitet und was man vermeiden sollte. Ein DBMS würde ich auch nicht selbstentwickeln. Erst mal fehlt mir dazu einfach das nötige Know-How und zweitens wozu auch? Es haben sich schon sehr viele andere den Kopf darüber zerbrochen. Ich habe schon Firmen erlebt, die meinten, sie wären Schlauer als Oracle und haben Datenbank-Funktionalität nachprogrammiert. Haben Zehntausende Euro verbraten und was kam raus? Eine instabile Lösung, die jegliche Form von Weiterentwicklung ausbremste.

Bearbeitet 3. September 2016 von Whiz-zarD

[MartinSt]

Moderne DBMS sollten einen direkten Import zB copy unter PostgreSQL unterstützen.