Folgendes Szenario:
Gegeben sind mehrere Messerfassungsbausteine, die kontinuierlich
Messwerte an einen FTP-Server senden. Die Ergebnisse liegen in
XML-Dateien vor. Pro Messzyklus wird eine XML-Datei erstellt, also
entstehen pro Tag einige hundert kleine XML-Dateien.
Ich möchte die Rohdaten im nächsten Schritt visualieren und Berechnungen
mit durchführen.
Ist es an dieser Stelle sinnvoll, die Daten weiterhin in den XML-Dateien
zu laden, wenn man sie braucht - oder ist dafür eine Datenbank sinnvoll?
Ich habe noch nie mit einer Datenbank gearbeitet, stelle mir aber jetzt
die Frage, ob es Sinn macht, sich damit etwas zu befassen und z.B. ein
Tool zu schreiben, dass mehrmals täglich ausgeführt wird und die in
XML-Format vorliegenden Daten in eine Datenbank migriert und ich für die
nachfolgende Auswertung dann auf die Datenbank zugreife?
Oder ist dort eher mit Kanonen auf Spatzen geschossen?
Bereits in einem Tag ist, bei pro Tag mehrere hundert Datensätze,
eine Visualisierung durch Lsden der XML Dateien vollkommener Blödsinn.
Natürlich kommen die Daten in eine (SQL-)Datenbank,
dann kann man auch auswählen, ob man die Werte von einem Tag, von einem
Monat, die Mittewerte wochenweise aus den Daten der letzten 1 Jahre
haben will.
Du solltest eher darüber nachdenken, ob nicht das Format der
Datenlieferdatei von XML auf ein vernünftiges Format umgestellt wird.
Ich würde allerdings die Dateien aufbewahren und nicht löschen,
denn dann kann an die Datenbank notfalls neu laden, falls du
auf Grund deiner Unerfahrenheit mit Datenbanken nochmal was
ändern willst, oder die die Datenbank mit Datenverlust abschmiert.
Danke für Eure Antworten!
MaWin schrieb:> Du solltest eher darüber nachdenken, ob nicht das Format der> Datenlieferdatei von XML auf ein vernünftiges Format umgestellt wird.
Was wäre denn ein vernünftiges Format? Es ginge bei manchen noch der
CSV-Datei-Export, da lägen dann die Daten schon in tabellierter Form vor
und das Migriertool würde wahrscheinlich weniger Lesezyklen benötigen,
um die Daten aus der csv-Datei zu lesen.
Eine Datenbank wäre sinnvoll, wenn du auf die Rohdaten mehr als einmal
zugreifst. (z.B, Mehrere verschiedene Berechnungen mit jeweils denselben
Daten). Wenn die Daten nur einmal angefasst werden, ist eine Datenbank
hierbei einfach überdimensionierter Schwachsinn.
XML ist schon in Ordnung. Wenn du fit in eine der typischen Quick &
Dirty-Scriptsprachen bist, würde sich Perl oder PHP anbieten. Dann
kannst du z.b. einfach html-dateien basteln, die dir jeder Browser wie
eine PowerPointPräsentation anzeigen kann ;)
eine einzelne datei fuer alles ist sicher sinnvoller wie zehntausende
kleiner dateien. falls die daten immer dieselben sind, wuerde ich eher
eine CSV dater verwenden als eine datenbank.
Manuel Kampert schrieb:> Würde mich jetzt auch interessieren was hier besser als XML sein sollte.> Mit Sicherheit nicht CSV.
XML ist doch Overkill für Messdaten (oder sind die so komplex
strukturiert?), da reicht normalerweise CSV dicke aber das ist hier gar
nicht der Punkt. Ich würde das wie Mawin machen, alles in eine DB rein,
dann kannst du sinnvoll, flexibel und schnell damit arbeiten, XML und
CSV lassen sich einfach in eine DB einpflegen. Und wie MaWin schon
schrieb, behalte die XML Dateien vorerst, falls du mit einer DB noch
nicht sicher umgehen kannst.
Datenbank hört sich am Anfang etwas mächtig an, aber wie bereits von
einigen im Vorfeld erwähnt, ist es sicherlich dann sinnvoll, wenn die
Daten verrechnet oder einfach modifiziert werden müssen. Ich habe gute
Erfahrungen mit sqlite (http://www.sqlite.org) gemacht, es ist
eigentlich nur eine Programmbibliothek, die aber gut SQL Befehle
verarbeitet. Mit MySql oder anderen müsstest Du noch einen Server
aufsetzen, was etwas oversize sein könnte. Ich denke auch, dass das
ständige Parsen der XML-Dateien auf die Dauer zu lange dauern wird.
Allerdings ist zu beachten, dass sqlite nur bedingt Multiuserfähig ist,
was MySQL ohne Probleme erledigt.
> Was wäre denn ein vernünftiges Format? Es ginge bei manchen noch der> CSV-Datei-Export, da lägen dann die Daten schon in tabellierter Form vor> und das Migriertool würde wahrscheinlich weniger Lesezyklen benötigen,> um die Daten aus der csv-Datei zu lesen
Ein vernünftiges Format wäre ein Format was auch eingelesen werden kann,
nicht nur von deinem Zielprogramm, sondern von möglichst vielen
Hilfsprogrammen.
Ein "Hilfsprogramm" ist das menschliche Auge, und da verfehlt XML schon
mal jede Übersichtlichkeit Dank 99% overhead.
CSV wäre sicher eine Option, denn der einzige Nachteil von CSV ist die
gegenüber XML fehlende Möglichkeit einen fremden Zeichensatz zu
spezifizieren - bei Zahlen ist der so was von sinnlos wie ein Loch im
Knie.
Du redest bei CSV von tabellierter Form, also mehrere Datensätze in
einer Datei, und bei XML von einem Datensatz pro Datei. Wenn ich das
richtig verstehe reduziert das also die Anzahl der Datein unter CSV
gegenüber XML drastisch, ein klares Argument zugunsten von CSV.
Beliebt sind auch Dateien die direkt SQL Anweisungen zum Insert der
Daten in die Datenbank enthalten, aber wenn deine Quellen das nicht
liefern können, bleibt ja nur die Auswahl zwischen XML und CSV.
>> Ich habe noch nie mit einer Datenbank gearbeitet, stelle mir aber jetzt> die Frage, ob es Sinn macht, sich damit etwas zu befassen und z.B. ein> Tool zu schreiben, dass mehrmals täglich ausgeführt wird und die in> XML-Format vorliegenden Daten in eine Datenbank migriert und ich für die> nachfolgende Auswertung dann auf die Datenbank zugreife?>> Oder ist dort eher mit Kanonen auf Spatzen geschossen?
Datenbank macht schon Sinn , und Du mußt auch nicht mit
Kanonen(Oracle11,IBM-DB2oder MS-SQL)auf deine Datenspatzen schießen.
SQLite (o.ä.) reicht dafür (für den Anfang)bestimmt aus.
Wenn Du Firefox als Browser verwendest, brauchst Du als DB-Manger nur
folgendes Adon:
https://addons.mozilla.org/de/firefox/addon/sqlite-manager/?src=search .
weitere Hilfe/DB-treiber usw. auf SQLite.org ,
die DB-Egine zum einbinden gibt es für zig Programmiersprachen
(von Basic über C , Pascal bis Java und noch Weitere , für Windows
,Linux.. )
MaWin schrieb:> Du redest bei CSV von tabellierter Form, also mehrere Datensätze in> einer Datei, und bei XML von einem Datensatz pro Datei. Wenn ich das> richtig verstehe reduziert das also die Anzahl der Datein unter CSV> gegenüber XML drastisch, ein klares Argument zugunsten von CSV.
Nicht alle Messgeräte liefern CSV-Dateien, aber alle XML-Dateien. Darum
hab ich auch alle auf XML umgestellt. Aber ich seh kein so großes
Problem darin, die Daten - z.b. um 12 Uhr und um 18 Uhr - durch ein
kleines Programm in die Datenbank zu schreiben.
Ich hab mir jetzt einfach mal den MySQL-Server heruntergeladen, muss den
aber erstmal zum Starten kriegen. Ich stelle mir das kleine C-Programm
einfach so vor - ich öffne die XML-Dateien, hole die Infos raus und
schreibe sie einfach mit nem Datenbankbefehl iin die Datenbank rein, so
kompliziert scheint das nicht zu sein, und das Hilfsprogramm kann ich
durch nen Batch auf dem Server zu gewünschen Uhrzeiten starten.
Datenbankfragender schrieb:> Ich hab mir jetzt einfach mal den MySQL-Server heruntergeladen,
Ich würde auch SQLite empfehlen, ist wesentlich einfacher in der
Anwendung und sollte für deine Bedürfnisse genau das richtige sein.
Wenn du zum Einlesen der XML-Files Python verwendest, musst du nichts
weiter installieren, da SQLite in Python schon integriert ist.
Johannes E. schrieb:> Wenn du zum Einlesen der XML-Files Python verwendest, musst du nichts> weiter installieren, da SQLite in Python schon integriert ist.
Ebenso Perl, PHP und Ruby also überall.
Datenbankfragender schrieb:> Nicht alle Messgeräte liefern CSV-Dateien, aber alle XML-Dateien.
Das ist schade und natürlich ein Grund für XML
> Ich hab mir jetzt einfach mal den MySQL-Server heruntergeladen, muss den> aber erstmal zum Starten kriegen. Ich stelle mir das kleine C-Programm> einfach so vor
Hättest du CSV, müsste das Programm die Daten gar nicht anfassen,
sondern bloss den Auftrag zum Reinladen der CSV-Datei in MySQL geben:
LOAD DATA LOCAL INFILE 'filename.csv' INTO TABLE `datatab`
FIELDS TERMINATED BY ';' LINES TERMINATED BY '\n'
(`field1`, `field2`)";
Lade dir doch mal das Paket XAMPP, wenn du einen "richtigen" Rechner als
Server verwenden willst - das gibts für Win, Mac und Linux. Da sind dann
fertig konfiguriert ein MySQL sowie ein Apache mit PHP (nebst PHP My
Admin) und ein FTP-Server drin - sozusagen ein "Rundum-Glücklich-Paket".
Musst du nur noch programmieren ... :-)
Alterntive: Hast du schon mal an ein NAS (z.B. Qnap oder Synology)
gedacht? Neben der Festplatte gibts auch für diese Dinger MySQL, Apache
mit PHP, FTP usw. Sowas nutze ich z.B. erfolgreich für die Entwicklung
von GPS-Tracker-Software ...
Manuel Kampert schrieb:> Würde mich jetzt auch interessieren was hier besser als XML sein sollte.> Mit Sicherheit nicht CSV.
JSON, zum Bleistift. Und was ist gegen CSV auszusetzen?
Wenn die XML-Dateien auf einem schnellen SSD-Laufwerk kannst du die auch
jedesmal komplett einlesen, sollte auch bei tausenden von Dateien sehr
schnell gehen. Auf einer normalen Festplatte per at-job scriptbasiert in
die datenbank schaufeln.
gruß jo
