Datenhaltung und Datenbank Größen

[Jens Hartmann]

Hallo zusammen.

ich will mal wieder eine Frage zur Datenbank stellen. Nachdem ich mein Programm eigendlich soweit fertig hatte, bin ich mittlerweile am verbessern und am BUG´s beseitigen. Mir ist bei der Datenbankeintragung meiner Datensätze aufgefallen, das niht alle Datensätze komplett geschrieben werden. Ist auch mittlerweile keine Problem mehr für mich das zu ändern.

Allerdings würde ich gerne mal wissen, wie es sinnvoller wäre. Bislang habe ich die Daten von einem COM-Port gelesen, anschließend geparst und dann in die DB geschrieben und in einnem VST zur Ansich gebracht.

Da mir beim Parsen Daten verloren gegangen sind, (Fehler aber schon behoben) habe ich zur Sicherheit noch eine weiter Tabelle in die Datenbank integriert, in der die gesamten ungeparsten Daten direkt nach dem Lesen von der Schnittstelle geschrieben werden.

Jetzt meine Frage: Nach dem Parsen schreibe ich die geparsten Date´n auch in die DB in eine andere Tabelle. Macht das Sinn. Oder wäre es besser vom Datenvolumen her. Nur die ungeparsten Daten in einer Tabelle zu halten und die Daten aus der DB zu lesen und dann erst zu parsen und zur Anzeige zu bringen.

Oder ist das vieleicht mit der doppelten Datenhaltung (ca. 4000 Datensätze/pro Tag) Sinnvoll um später mal Fehler suchen.

Danke schon mal für Eure Hilfe und

Gruß Jens

[exilant]

Zitat von Jens Hartmann:

Oder ist das vieleicht mit der doppelten Datenhaltung (ca. 4000 Datensätze/pro Tag) Sinnvoll um später mal Fehler suchen.

4.000 Datensätze am Tag sind Peanuts. (Ich gehe davon aus, dass die Sätze von eher geringer Größe sind wenn sie seriell angeliefert werden...) Wenn Du Deinen Parser noch nicht im Griff hast, logge die Daten doch einfach "raw" mit Timestamp in ASCII Dateien mit. die lassen sich schön zippen oder sonstwie komprimieren. Das Loggen nimmst Du dann einfach raus wenn es nicht mehr gebraucht wird. Beides in die Datenbank zu schreiben halte ich für überflüssig.

Grüße

[Jens Hartmann]

Gut,

aber ist es dann sinnvoll die geparsten oder die ungeparsten zu schreibe. Ich würde sagen die geparsten, weil dann vermutlich später das laden schneller gehen wird, weil ich ja dann auf das parsen verzichten kann.

Gruß Jens

[mkinzler]

Und zudem dann eine bessere Abfragemölglichkeit besteht

[Chemiker]

Hallo Jens Hartmann,

ich speichere Messwerte von einer SPS und speichere sie so wie sie vom COM-Port kommen mit einem Zeitstempel. Es fallen ca. 100.000 Datensätze pro Tag an. Das Abspeichern der Roh-Daten in eine Datenbank hat den Vorteil, dass ein Backup während des Betriebes erstellt werden kann. Zudem hat der COM-Port nur eine begrenzte Kapazität.

Bis bald Chemiker

[Jens Hartmann]

Zitat von mkinzler:

Und zudem dann eine bessere Abfragemölglichkeit besteht

Das sehe ich genau so, ist halt nur die Frage, ob...

Zitat von Chemiker:

ich speichere Messwerte von einer SPS und speichere sie so wie sie vom COM-Port kommen mit einem Zeitstempel.

es Sinn macht, die Datenhaltung zu verdoppeln. Momentan mache ich es genau so. Daten einmal direkt und ungeparst mit TimeStamp und geparst für die Abfrage. Persönlich gesehen finde ich das auch eigendlich gar nicht so falsch. Denn so hätte ich ja immer die Möglichkeit, bei Fehlern die eventuell erst später mal auftauchen diese einfacher Nachzuvollziehen.
Vieleicht sollte ich es einfach so machen.

Gruß Jens

[Chemiker]

Hallo Jens Hartmann,

die limitierende Größe ist der COM-Port. Die Datenbank sollte damit keine Schwierigkeit haben.

Bis bald Chemiker

[Die Muhkuh]

Falls das Parsen zu viel Zeit in Anspruch nimmt, schreib die Daten doch erst mal so in die Datenbank und schreibe einen Hintergrundprozess, der die ungeparsten Daten aus der DB ausliest, sie parst und anschließend wieder zurückschiebt.

[Jens Hartmann]

Zitat von Muhkuh:

Falls das Parsen zu viel Zeit in Anspruch nimmt, schreib die Daten doch erst mal so in die Datenbank und schreibe einen Hintergrundprozess, der die ungeparsten Daten aus der DB ausliest, sie parst und anschließend wieder zurückschiebt.

Ich glaube nicht das das Parsen das Problem sein sollte. Es handelt sich um Datensätze mit einer Länge von max. 255 Zeichen die in max. 6 Teilabschnitte geparst werden. Das stellt keine Problem da.

Zitat von chemiker:

die limitierende Größe ist der COM-Port. Die Datenbank sollte damit keine Schwierigkeit haben.

Joh, sehe ich genau so. deshalb lasse ich die SERVICE_TABLE nämlich auchin der DB, zusätzlich ist mir dadurch eben noch aufgefallen, das der TimeStamp mir auch noch eine optionalen Zeitvergleich meiner Software zur Hardware ermöglicht.

Gruß Jens