3. Daten nach Beenden des Programms speichern

Daten nach Beenden des Programms speichern

  • G

    Hallo,

    wir haben an der Uni ein Projekt, bei dem wir mit einem Mikrocontroller Temperaturen messen. Nun sollen die (auf Abruf) an den PC übermittelt werden und dort auch nach beenden des Programms noch zur Verfügung stehen.

    Ein Datensatz enthält im Moment die Informationen Datum, Uhrzeit und Temperatur.
    Geplant ist, dass maximal alle 10 Minuten ein Wert aufgenommen wird, auf dem Mikrocontroller zwischengespeichert wird und dann eben übertragen wird.
    Am Ende soll das ganze auch noch erweiterbar sein um vielleicht noch andere Messgrößen aufnehmen zu können, damit man damit zB eine Hausautomation realisieren kann. Das ganze ist wie gesagt ein Uni-Projekt und muss nicht kommerziell nutzbar sein, also bitte keine Kommentare über den Sinn 😉

    Nun geht es darum, wie ich die Datensätze am sinnvollsten auf den PC speichere. Reicht eine "einfache" Textdatei (oder CSV) oder macht es Sinn, eine Datenbank zu nutzen? Oder gibt es eine einfache Alternative, an die ich noch gar nicht gedacht habe?

    Vielen Dank für eure Anregungen.
    Moki

    PS: Ich hoffe ich bin im richtigen Forum.

    0
  • Mod

    Du suchst also wahrscheinlich eine möglichst einfache Lösung, oder? Kommt ein bisschen drauf an, was du später mit den Daten machen möchtest. Wenn du sie später bloß mit anderen Programmen verarbeiten möchtest, dann bietet es sich an, die Daten einfach in einer Tabelle zu speichern, eine Zeile pro Zeitpunkt, Spalten getrennt mit Tabulatoren. Viele Programme zur Datenverarbeitung können ganz hervorragend mit solchen Tabellen umgehen. Da ist es dann in der Regel kein Problem, wenn das Format später noch mehr Spalten bekommt, wenn du dafür deine Auswertungsskripte schreibst.

    Beim Zeitstempel würde ich mir noch überlegen, ob du wirklich eine menschenlesbare Zeitangabe brauchst oder ob es auch eine Zeitangabe tut, mit der ein Computer besser umgehen kann, zum Beispiel Unixzeit als Zahl. Oder einfach beides, computerfreundliches Format und menschliche Übersetzung.

    Eine Datenbank halte ich hier für Overkill, es sei denn, du erwartest noch ein massives Wachstum des Projektes.

    0

  • SeppJ schrieb:

    Beim Zeitstempel würde ich mir noch überlegen, ob du wirklich eine menschenlesbare Zeitangabe brauchst oder ob es auch eine Zeitangabe tut, mit der ein Computer besser umgehen kann, zum Beispiel Unixzeit als Zahl. Oder einfach beides, computerfreundliches Format und menschliche Übersetzung.

    Davon möchte ich grundsätzlich abraten.
    Die selben Daten redundant abspeichern führt bloss zu der unnötigen Frage "was mach ich wenn die Werte nicht übereinstimmen?".

    Ich würde das gute alte "YYYY-MM-DD hh🇲🇲ss.fff" Format vorschlagen. Das ist eindeutig (im Gegensatz zu Formaten wie "YY/MM/DD" die als "YY/DD/MM" fehlinterpretiert werden könnten), menschenlesbar, als String sortierbar, und wird vom Programmen üblicherweise automatisch als Datum verstanden.

    Wenn man ISO-konform sein will kann man auch "T" statt des Leerzeichens als Trennzeichen verwenden.
    Und evtl. kann es Sinn machen die Zeitzone mit reinzukodieren: "YYYY-MM-DD hh🇲🇲ss.fff+TZ", also z.B. "2013-05-02 23:00:00.000+02" für 23:00 mitteleuropäische Sommerzeit.

    Alternativ kann es Sinn machen die Zeiten alle als UTC zu erfassen. Dadurch bleibt die Sortierbarkeit als String auch über die Sommerzeitgrenzen (oder andere Zeitzonenwechsel) gegeben. Evtl. will man dann den aktuellen Offset auch mit abspeichern, um die Lokalzeit anzeigen zu können. Das sollte dann aber in einer eigenen Spalte geschehen, damit es nicht fälschlicherweise für die Zeitzonenangabe gehalten mit der die Zeitangabe zu interpretieren ist.

    Für das Beispiel oben ergäbe das dann z.B. die beiden Spalten "2013-05-02 21:00:00.000Z" und "+02".

    GER_Moki schrieb:

    Oder gibt es eine einfache Alternative, an die ich noch gar nicht gedacht habe?

    Viel einfacher als CSV wird's nicht mehr.

    Und "einfach" ist relativ. Eine Datenbank ala SQLite zu verwenden ist auch einfach, wenn man sich damit schon auskennt. Wenn man es erst lernen muss braucht man aber sicher viel länger als für CSV Files.
    Und was manuelle Kontrolle/Fehlersuche angeht sind CSV Files einer Datenbank in diesem einfachen Fall auch haushoch überleben.

    ps:
    Ein Tip noch: schreib bei CSV die Spaltennamen in die erste Zeile. Die meisten Programme sollten damit umgehen können, und es erleichtert das Arbeiten mit den Files ungemein wenn man nur "First line contains column names" beim Importieren anhakerln muss, statt mühsam alle Spaltennamen in der Doku nachzulesen und dann per Hand reinzuschreiben.

    0
  • G

    SeppJ schrieb:

    Du suchst also wahrscheinlich eine möglichst einfache Lösung, oder?

    Ja, einfach zu verstehen und umzusetzen.

    SeppJ schrieb:

    Kommt ein bisschen drauf an, was du später mit den Daten machen möchtest. Wenn du sie später bloß mit anderen Programmen verarbeiten möchtest, dann bietet es sich an, die Daten einfach in einer Tabelle zu speichern, eine Zeile pro Zeitpunkt, Spalten getrennt mit Tabulatoren.

    Die Daten sollen "nur" im (eigenen) Programm angezeigt werden (Tabellenform, Verlaufskurve, vielleicht Min/Max-Berechnung in einem Zeitraum...), also brauch ich kein Format, mit dem andere Programme klarkommen, wäre nachtürlich netter, muss aber nicht.

    hustbaer schrieb:

    Und "einfach" ist relativ. Eine Datenbank ala SQLite zu verwenden ist auch einfach, wenn man sich damit schon auskennt. Wenn man es erst lernen muss braucht man aber sicher viel länger als für CSV Files.

    Damit wird es ein CSV-File werden. SQLite ist ein Buch mit 7 Siegeln und leider ist (für mich als Elektrotechnik-Student) keine Zeit, mich mit Datenbanken auseinanderzusetzen 😞

    hustbaer schrieb:

    Ein Tip noch: schreib bei CSV die Spaltennamen in die erste Zeile.

    Werd ich machen 🙂

    Danke euch beiden!

    0
  • Mod

    GER_Moki schrieb:

    hustbaer schrieb:

    Ein Tip noch: schreib bei CSV die Spaltennamen in die erste Zeile.

    Werd ich machen 🙂

    Mach davor noch ein '#'. Das verstehen viele externe Programme (falls sie irgendwann doch mal benutzt werden) als Kommentarzeichen.

    Ich persönlich würde statt CSV eine Liste ohne Kommas nehmen. Die Daten die du beschreibst werden wohl kaum Whitespace enthalten, also kein Grund für einen zusätzlichen Separator. Es gibt einen Grund, warum viele Programme gut mit Spalten umgehen können: Es ist in den meisten Sprachen* sehr einfach zu programmieren. Wenn du die Kommas weg lässt, kannst du dir das selber zu nutze machen.

    *: welche Sprache soll's eigentlich sein? Eventuell bietet die Standardbibliothek der Sprache schon etwas (halb-)fertiges.

    0

  • Also ich sag grundsätzlich CSV, auch wenn ich ; oder ein Tab als Trennzeichen verwende.
    (Richtigerweise müsste man DSV sagen, aber der Begriff ist halt sehr unüblich, verstehen viele nicht)

    0
  • ?

    Wenn du das ganze erweitern willst, dann bietet sich auch XML und JSON an.

    Letzte beiden blähen im Gegensatz zu csv die Datenmenge natürlich auf, aber dafür
    sind sie dann absolut eindeutig und können gut weiterverarbeitet werden.
    Insbesondere wenn hinterher noch eine Webseite damit gefüttert werden soll.

    Natürlich sollte man nen XML Parser dafür verwenden und sich etwas in DOM einarbeiten.

    0

  • XML finde ich bei sowas unpraktisch, weil man nicht einfach Daten anhängen kann.
    Es geht natürlich ohne gleich immer das ganze File neu zu schreiben, ist aber etwas frickelig.

    Oder man verwendet ein XML-Fragment File. Also ein File wo die XML-Deklaration und das Root-Element weggelassen werden, und nur die "inneren Elemente" geschrieben werden.
    Da kann man dann wieder einfach anhängen.

    Von den XML Parsern sollte damit eigentlich jeder umgehen können (behaupte ich mal ... hoffentlich).
    Wie gut der Support bei Tools wie Excel, Access etc. ist weiss ich nicht.

    0
  • Z

    Eindeutig CSV.

    Wobei du sogar soweit gehen kannst, das Trennzeichen komplett wegzulassen, wenn der Wertebereich bereits vorher feststeht (was bei dir der Fall zu sein scheint). Zwar dann vll nicht mehr wirklich menschenlesbar, aber platzsparender wirst du es ohne Komprimierung nicht hinbringen

    dann sieht ein Datensatz vll nur so aus

    201305040000000020

    4 Zeichen Jahr
    2 Zeichen Monat
    2 Zeichen Tag
    2 Zeichen Stunde
    2 Zeichen Minute
    2 Zeichen Sekunde
    4 Zeichen Temperatur

    0

  • zwutz schrieb:

    Zwar dann vll nicht mehr wirklich menschenlesbar, aber platzsparender wirst du es ohne Komprimierung nicht hinbringen

    Doch, klar, jede Binärvariante ist viel Platzsparender.
    Bzw. sogar BASE64-kodierte Binärdaten, wenn man es unbedingt als Textfile behandeln können will.

    Sobald man auf menschenlesbar verzichtet geht einiges.

    0
  • V

    zwutz schrieb:

    aber platzsparender

    Wie irrelevant.

    zwutz schrieb:

    dann sieht ein Datensatz vll nur so aus

    201305040000000020

    4 Zeichen Jahr
    2 Zeichen Monat
    2 Zeichen Tag
    2 Zeichen Stunde
    2 Zeichen Minute
    2 Zeichen Sekunde
    4 Zeichen Temperatur

    Statt vorher

    2013,5,4,0,0,0,20

    Ok, doofes Beispiel, aber Du hast zufällig mehr gebraucht. 🤡

    0
  • B

    Lest mal den Titel: "Daten nach Beenden des Programmes speichern"
    Ich würde das vor dem Beenden machen. Bei wenigen Datensätzen lesbar als ASCII-Text, bei vielen (> 1000) evtl. binär in eine simple Datei.

    0

  • ...

    0
  • ?

    berniebutt schrieb:

    Lest mal den Titel: "Daten nach Beenden des Programmes speichern"

    Ein Merker ward geboren ...

    0

  • berniebutt schrieb:

    Lest mal den Titel: "Daten nach Beenden des Programmes speichern"
    Ich würde das vor dem Beenden machen. Bei wenigen Datensätzen lesbar als ASCII-Text, bei vielen (> 1000) evtl. binär in eine simple Datei.

    1000 ist viel?
    Heisst das ein 100 KB Textfile ist schon gross?

    Also ne.
    1000 ist nix.
    Und wie viele Datensätze es werden sollte auch ziemlich egal sein.

    0
  • Mod

    Ich würde das nicht von der Datenmenge abhängig machen, sondern nach dem, was man damit vor hat. Ich selber speichere für meine Zwecke öfters mal viele Gigabyte pro Run, aber ich schreib das trotzdem bloß in eine einfache (komprimierte) ASCII-Datei im Spaltenformat. Eben weil
    a) Ich das Zugriffsmodell einer Datenbank gar nicht benötige
    b) Weiterverarbeitung und Wiedereinlesen besonders einfach sind
    Was der Threadersteller beschreibt, klingt ganz so, als läge dort ein ähnlicher Fall vor.

    Wenn man keine Datenbank braucht, dann kann man sich den Mehraufwand sparen. Mit Platzargumenten braucht man auch nicht kommen. Wenn man in Größenordnungen kommt, in denen Platz relevant ist, dann komprimiert man die Daten. Damit kommt man auf den gleichen Platzbedarf (oder sogar weniger) wie bei einem Binärformat, aber ohne dessen Nachteile (Portabilität, Manipulierbarkeit, Lesbarkeit) . Der Vorteil eines Binärformates wäre eine höhere Verarbeitungsgeschwindigkeit (Lesen und Schreiben).

    0
  • G

    berniebutt schrieb:

    Lest mal den Titel: "Daten nach Beenden des Programmes speichern"
    Ich würde das vor dem Beenden machen. Bei wenigen Datensätzen lesbar als ASCII-Text, bei vielen (> 1000) evtl. binär in eine simple Datei.

    Ja, das war auch meine Intention. Ich könnt auch einen Roman als Titel schreiben, aber das ist auch nicht besser...

    So, wir haben uns intern in der Gruppe jetzt auf eine CSV-Datei geeinigt (auch wenn das Trennzeichen wohl ein Space wird, lass ich es mal bei der Bezeichnung).

    Am Ende soll es so aussehen, dass der Anwender in einem Dropdownmenü auswählt, dass er alle Datensätze mit einem Wert größer x und kleiner y haben will. Und dann auch nur die, die zwischen dem 1.1.13 und 31.3.13 aufgenommen wurden.
    Macht es Sinn hier eine std::list durchzugehen, die ich mir beim Programmstart anlege oder eben die CSV zu parsen und filtern?

    0
  • Mod

    Macht es Sinn hier eine std::list durchzugehen, die ich mir beim Programmstart anlege oder eben die CSV zu parsen und filtern?

    std::list macht praktisch nie Sinn, außer im Informatikunterricht.

    Was du nun beschreibst klingt wieder ziemlich datennbankartig. Vielleicht drückst du dich auch doof aus. Jedenfalls interessiert doch niemanden, wie man das Programm bedient, sondern die Frage ist, was es tun soll. Da wir keine Ahnung haben, welche Werte du meinst, ist deine Frage schwer zu beantworten, welche Technik die beste ist.

    An anderer Stelle bestätigt sich eine Befürchtung, die ich schon hatte, als du sagtest, dass das Programm einfache Plots erstellen soll: Jetzt misst das Programm, speichert Daten, zeichnet Graphen, verarbeitet Daten nach Kriterien, zeigt Daten an. Eierlegende Wollmilchsau? Lass ein Programm genau eine Sache machen und mach diese Sache gut!
    Am ende kannst du dann mehrere Funktionen zu einem übergeordneten Programm zusammenfassen, das dann die Schnittstellen/Bibliotheken der spezialisierten Programme benutzt. Auf diese Weise kannst du dir auch sehr viel Entwicklungsarbeit sparen. Denn beispielsweise ein Plotprogramm zu schreiben braucht heute niemand mehr. Da gibt es tausende fertige Lösungen und alle sind sie viel besser als alles, was man in ein paar Mannwochen schreiben könnte.

    0
  • G

    Okay, ich versuchs nochmal:

    Ich bekomme von einem Mikrocontroller Datensätze mit Zeitstempel umd einem Wert (z.B. einer Temperatur). Die möchte ich nun filtern können (nach Zeitraum, Min-Max-Werte...) und erstmal in Tabellenform anzeigen.

    Edit: Das holen der Daten vom Mikrocontroller muss ich "manuell" durch einen Button anstoßen.

    0
  • Mod

    GER_Moki schrieb:

    Ich bekomme von einem Mikrocontroller Datensätze mit Zeitstempel umd einem Wert (z.B. einer Temperatur). Die möchte ich nun filtern können (nach Zeitraum, Min-Max-Werte...) und erstmal in Tabellenform anzeigen.

    Dann benutz doch ein Tabellenkalkulationsprogramm!
    Aufwand für dich: 0 (da du die Daten schließlich schon als CSV exportierst)
    Leistungsfähigkeit und Flexibilität der Lösung gegenüber einer Eigenentwicklung: 1337 Mal besser.

    Edit: Das holen der Daten vom Mikrocontroller muss ich "manuell" durch einen Button anstoßen.

    Das ist wieder so ein Detail, das uns überhaupt gar nichts sagt.

    0
Anmelden zum Antworten