Was mache ich wenn meine Tabelle voll ist?

[p80286]

Zitat von Bernhard Geyer:

Zitat von Dejan Vu:

Gewährleistung, Rückverfolgbarkeit, Fehlersuche. Die Herstellungsverfahren sind neu und insofern muss das ein paar Jahre gesichert werden. Ob nun alle 500 oder nur die Eckwerte sei mal dahingestellt.

Dann würde ich alle Messwerte einer Geräts in eine Datei/einem (Blob-)Feld speichern.
Da du jetzt nicht weiß was damit gemacht wird ist es m. E. noch nicht sinnvoll diese normalisiert einzeln in eine DB zu speichern.

Anfrage meines Chefs: "vor drei jahren sollten an Akte X folgende Änderungen gemacht worden sein, kann man das nachvollziehen?"
Das konnte ich verneinen, da die gefragte Änderung nicht protokolliert wird. Andere hingegen schon.

Im Zweifel werden solche Daten gebraucht, bis das die Verjährungsfrist bzw. Aufbewahrungsfrist abgelaufen ist. Und manchmal nicht "irgendwo" sondern "at your fingertip".

Gruß
K-H

[mkinzler]

Das ist keine Frage, die man so einfach auf die Schnelle beantworten kann.

Sind es einzelne unabhängige Werte oder Sätze ( z.B. verschiedene Messwerte zu einem Zeitpunkt/Werkstück)?/Muss auf die einzelnen Werte zugegriffen werden oder auf einen "Satz"?
In einen Blob könnte man problemlos jeweils einen Satz ablegen, könnte dann aber nicht mehr so einfach (per SQL) auf die einzelnen Werte zugreifen. Einfache Statistiken per SQL Aggegate würden also nicht mehr funktionieren.

[Bernhard Geyer]

Zitat von mkinzler:

In einen Blob könnte man problemlos jeweils einen Satz ablegen, könnte dann aber nicht mehr so einfach (per SQL) auf die einzelnen Werte zugreifen. Einfache Statistiken per SQL Aggegate würden also nicht mehr funktionieren.

Die Frage ist wie schnell eine "übliche" SQL-Datenbank auf Aggregatfunktionen reagiert wenn hier jetz Mrd-Datensätze drin liegen.
Solche Auswertungen macht man ja üblich in einer "OLAP-Optimierten" Struktur.

[mkinzler]

Wenn sowieso ein Data Warehouse eingesetzt wird, besteht das Problem eh nicht, da man in diesem Fall durch die "Archivierung" im DW den "Aktivzeitraum" kleinhalten kann.
Mein Beitrag war auch nicht als "Kontra"-Beitrag gegen Blobs gemeint. Sondern sollte nur darauf hinweisen, dass man genauere Untersuchungen/Überlegungen treffen sollte und es "die" Lösung per se nicht gibt.

[stahli]

Ich denke auch, man könnte für diesen Zweck eine NoSQL-DB in Erwägung ziehen.
Kann man einfach alles mehr oder weniger unstrukturiert reinwerfen und bei Bedarf wieder danach suchen.

[mkinzler]

Zitat von stahli:

Ich denke auch, man könnte für diesen Zweck eine NoSQL-DB in Erwägung ziehen.
Kann man einfach alles mehr oder weniger unstrukturiert reinwerfen und bei Bedarf wieder danach suchen.

Da die Daten doch sehr strukturiert sind, bringt m.E NO SQL keine Vorteile.

[stahli]

Ich hatte es so verstanden, dass es um Logs über einen längeren Entwicklungs/Produktionszeitraum geht.
Da könnten sich die zu speichernden Information auch durchaus noch ändern.

[himitsu]

Wenn man viele Daten hat und auch die Möglichkeit bieten will die auszuwerten (nicht all zu langsam), dann könnte man auch überlegen gleich ein DataCenter einzusetzen, welches auf große Datenmengen spezialisiert ist und wo man auch noch Funktionen für die Auswertung (inkl. Caching) bekommt.

Und dann wurde schonmal angesprochen, daß einige DBMS verschiedene Tabellentypen unterstützen, wo es auch welche für große Datenmengen gibt.
MySQL hat z.B. eine Tabelle, die ist für viele Daten ausgelegt (weniger Overhead, kein Index, keine Referenzen usw.), aber dafür halt schlecht/garnicht änderbar ist. (bestehende Datensätze ändern oder löschen).
Sowas wird gern für Logdateien verwendet, was man hier also quasi vor hat.

[Sir Rufo]

Auch wenn ich jetzt gleich Haue kriege, aber mit einer Zwischenschicht (hatten wir ja erst kürzlich) ist es schon wieder wurstegal, ob es diese Beschränkung auf der DB gibt.

Man bringt der Zwischenschicht bei, damit umzugehen entweder durch den Tausch der Datenbank oder entsprechendes Handling mit mehreren Tabellen.