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?
kommt auf die Stuktur der Daten an. Wenn es etwas ist was sich sehr gut als Tabelle darstellen lässt, würde ich es auf jeden Fall mit einer DB machen.
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.
Wenn Messwerte je nach Alter in zunehmenden Zeitintervallen zusammengefasst werden sollen, dann können Oetikers rrdtools sinnvoll sein.
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.
Würde mich jetzt auch interessieren was hier besser als XML sein sollte. Mit Sicherheit nicht CSV.
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 ;)
:
Bearbeitet durch User
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.
Schon mal http://de.wikipedia.org/wiki/RRDtool gesehen? Das sammelt Meßwerte und malt schöne Bilder.
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.
Schwen Gel schrieb: > Ebenso Perl, PHP und Ruby also überall. Ja richtig, überall außer bei C. Datenbankfragender schrieb: > Ich stelle mir das kleine C-Programm einfach so vor ...
Was sind das fuer Messgeraete, welche Daten ueber xml liefern, und diese dann ueber FTP raufladen.
Johannes E. schrieb: > Ja richtig, überall außer bei C. SQLite in C zu nutzen ist allerdings trivial.
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?
Johannes E. schrieb: > Ja richtig, überall außer bei C. Das ist eine C-Bib. die lässt sich überall dazulinken, dafür wurde sie auch entwickelt.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.