Speicherung von vielen Dateien in Datenbank

[george]

Hallo,

ich hab mal wieder ein paar Konzeptfragen zum Thema Speichern von Daten in einer Datenbank.
Ich bin gerade dabei einen Mess- und Prüfplatz umzusetzen. Bei den Messungen werden im Laufe der Zeit viele separate Messdateien entstehen. Bisher war es immer so, dass die Messwerte in separate Textdateien gespeichert wurden. Dies möchte ich aber gerne durch ein effektives Speichermanagment ersetzen. Ich gehe davon aus, dass sich Messungen von > 100.000 ergeben werden.
Als Datenbankserver steht mir ein MS SQL zur Verfügung.

Jetzt meine Frage:

Wie würdet ihr dies am effektivsten Umsetzen?

- Speichern der Messdaten in einer separaten Textdatei und den Pfad in der Datenbank speichern

- Speichern aller Messwerte in Datenbank. Für jede Messung wird eine neue Tabelle erzeugt

- Speichern alle Messwerte in Datenbank. Messwerte werden in einer globalen Tabelle integeriert.

Wäre euch für Anregungen sehr dankbar
Gruss george

[Hyperion]

Dazu müßte man vor allem wissen, woraus und wie sich eine Messung zusammensetzt! Erst daraus kann man ein realtionales Schema basteln, (ggf. auch mit Vortsufe eines ERD o.ä.) und gucken, wie das am besten im relationalen Sinne abgebildet werden kann.

Danach kann man sich überlegen, inwiefern man die DB ggf. optimieren müßte im Sinne von Speichermanagement usw. An der relationalen Struktur würde ich (mit meiner geringen Erfahrung ) jedenfalls nichts ändern.

Sollte es darauf hinauslaufen, dass eine Messung einen großen Batzen an binären Daten enthält, wäre eine externe Datei imho besser. Ich bin kein Freund von Blobs - wozu gibts eine Dateisystem? Aber alleine für die Metadaten der Messung wäre eine DB sicherlich ideal ... und 100.000 Einträge sind noch nicht unbedingt ein besorgniserregende Größe.

Und zu MS SQL: *Ihhhhgitt* Wer lizenziert so nen Schrott blos? Mir konnte noch niemand die Existenzberechtigung von diesem Teil vermitteln ... Ich weiß ja, dass es leider immer noch Software gibt, die diesen Kram voraussetzen, aber ich würde immer etwas anderes wählen, wenn ich halbwegs die Wahl hätte.

[BlackJack]

@george: Was immer Du auch machst: Eine Tabelle pro Messung ist keine gute Idee. "Variable" Tabellennamen sind schlechter Stil. Also dann eher eine grosse Tabelle mit einer ID für die Messung zu der die Daten gehören.

Anonsten ist es wichtig was für Daten, wieviele, und vor allem: Welche Anfragen sollen effizient möglich sein?

[george]

Hallo,

erst mal danke für eure Antworten. Eine Messdatei ist immer wie eine Matrix aufgebaut. Zeilen sind definitiv variable. Bei den Spalten bin ich mir noch nicht ganz sicher, was da alles mit rein muss.

Naja, MS SQL. Ich habe auch für einen MySQL Server geworben. Problem ist aber, dass diese Dinge durch unseren Admin(Microsoft Fanatiker--> auch bei Server) entschieden werden. Dieser handelt dann mal nach der Devise: "Ihr könnt gerne eure Vorschläge mit einbringen, aber entscheiden werde ich!"

gruss george

[Hyperion]

Hallo,

erst mal danke für eure Antworten. Eine Messdatei ist immer wie eine Matrix aufgebaut. Zeilen sind definitiv variable. Bei den Spalten bin ich mir noch nicht ganz sicher, was da alles mit rein muss.

Variable Zeilen sind ja nicht das Problem - im Gegenteil sind das ja grad die Tupel in dem relationalen Schema Über Spalten sollte man sich dann eben schon vorher klar sein! Also versuche am besten vorher die Struktur der Daten zu überblicken und sich darüber klar zu werden. Wenn später eine Spalte dazukommt ist es ja auch nicht tragisch ... nur bei "n" Spalten wäre es eben ein Desginfehler.

Naja, MS SQL. Ich habe auch für einen MySQL Server geworben. Problem ist aber, dass diese Dinge durch unseren Admin(Microsoft Fanatiker--> auch bei Server) entschieden werden. Dieser handelt dann mal nach der Devise: "Ihr könnt gerne eure Vorschläge mit einbringen, aber entscheiden werde ich!"

Ok Gott ... ein Klicki-Bunti-Admin Nicht falsch verstehen, ich bin da kein Fanatiker, aber wie gesagt einen guten Grund für dieses RDBMS kenne ich nicht

[Leonidas]

Ich habe auch für einen MySQL Server geworben.

Naja, MySQL ist da nicht groß besser, was die Releasepolitik und die Features angeht ist es eher ein durchwachsendes Beispiel für Freie Software. Viel eingesetzt, weil es eben bekannt ist, weniger weil es sonderlich gut ist.

[gerold]

durch ein effektives Speichermanagment ersetzen

Hallo george!

So ein Datenbanksystem ist weder schnell beim Lesen, noch beim Schreiben von großen Datenblöcken. Schnell ist nur das Auffinden von wenig Daten aus einem rießigen Datenblock.

Wenn du viele Daten, ungefiltert einfach nur schnell speichern musst, dann ist eine lokale Textdatei nicht zu übertreffen.
Wenn du nicht nur schnell speichern, sondern auch die Daten schnell auffinden musst, dann bist du mit einer lokalen Datenbank (SQLite) gut bedient.

Das Ablegen der Daten in einem großen Datenbanksystem ist nur dann ratsam, wenn die Daten nicht unbedingt sehr schnell geschrieben werden müssen UND wenn die Daten von mehreren Clients abgerufen werden müssen. Und das auch nur, wenn aus einem großen Datenbrocken, für die Clients immer nur recht wenig Daten wichtig sind.

Es gibt natürlich auch Zwischenstufen. Z.B. kannst du Daten, lokal aufbereiten und erst gefiltert von einem Datenbanksystem verarbeiten lassen. Usw.

Sei dir aber immer bewusst: So schnell der MS SQL-Server auch ist. Er ist eine sehr sehr lahme Schnecke im Gegensatz zu einer lokalen kleinen Datenbank wie Access oder SQLite. Und SQLite ist eine Schnecke beim Schreiben von Daten, im Gegensatz zu einer Textdatei, an die Daten einfach angehängt werden.

Ich durfte diese Erfahrung selbst machen, als ich von Access auf MS SQL-Server umgestiegen bin.

Ich sollte jetzt schlafen gehen...

mfg
Gerold

[BlackJack]

Eventuell könnte eine Datenbank wie HDF5 die Textdatei schlagen. Da können die Daten Binär geschrieben werden und lassen sich von Python aus auch bequem und schnell als `numpy`-Arrays laden bzw. aus solchen speichern.

Aber auch da kommt es wieder darauf an, was mit den Daten überhaupt gemacht wird.

[george]

Hallo,

danke für eure Antworten. Momentan spricht alles für die reine Datenbanklösung.

Das Schreiben der Messdaten ist absolut zeitunkritisch aber folgende Dinge:
- schnelles Auffinden von Daten (über Suchmasken / Filter)
- Verwendung von mehreren Clients
sind unabdingbar

Gruss
george