Was mache ich wenn meine Tabelle voll ist?

[Bernhard Geyer]

Zitat:

Zitat von vagtler (Beitrag 1283193)

Zitat:

Zitat von Dejan Vu (Beitrag 1283167)

[...] Zur Grenze, eine Beispielanwendung: In einer Fabrik wird pro Sekunde ein Bauteil mit 500 Messwerten durchgemessen, die Fabrik läuft 24/7. Das sind am Tag 43 Mio Zeilen, wenn ich mich nicht verrechnet habe. Da ist die Tabelle im Nonstopbetrieb nach 49 Tagen voll. Das ist keine Phantasie, sondern im Solarzellenbereich Realität. Da lob ich mir doch eine DB, der es wurscht ist, wie viele Zeile in die Tabelle passen.

Wobei ich mir bei solchen Anwendungsfällen nicht die Frage stellen würde, ob man hier nicht in besser eine entsprechend leistungsfähige Key-Value-Store-Datenbank einsetzt.

Genau. Oder ist es wirklich nötig das man in 2 Jahren noch weis was vor 2 Jahren diese 500 Messwerte genau waren? Hier ist eher zu überlegen diese Daten mit der Zeit (automatisiert) Einzdampfen um hier nur die Statitischen Daten der Messwerte über die Zeit zu haben.

[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.

[Bernhard Geyer]

Zitat:

Zitat von Dejan Vu (Beitrag 1283197)

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.

[Dejan Vu]

Für die Archivierung könnte man das durchaus machen. Aber es ist auch so, das TB-Platten weitaus billiger sind, als die Manpower, um eine Archivierung und ein entsprechendes Retrieval zu implementieren.

Ehrlich gesagt weiß ich nicht, was die mit den alten Daten machen, aber beim Aufbau der Fabrik und in den ersten 2-3 Jahren hat man sich Daten der letzten 6-10 Monate durchaus angeschaut und das waren dann eben so viele. Was die heute damit machen? Vermutlich liegen die frustriert in einer Partition rum und werden nie selektiert. Nie! Die armen Daten. Komplett vergessen. Opfer der Sammelwut. :cry:

[joachimd]

Zitat:

Zitat von Der schöne Günther;1283182Wenn jetzt jeder hier gesagt hätte [I

"WAS!?! 2^31 haben bislang für jede Anwendung auf der Welt gereicht, und du willst die einzige Ausnahme sein!?![/I]" hätte ich mich schluchzend unter den Tisch verkrochen aber jetzt bin ich wieder etwas beruhigter.

Ich habe in meinen 15 Jahren als ADS Betreuer noch keinen getroffen, der auch nur annähernd an diese Grenze kam. das heißt jetzt nicht, dass es das nicht gibt - aber unter unseren Kunden eben bisher nicht. Und wir haben viele - die Dunkelziffer der ganzen Local Server Anwender mal ausgeschlossen.

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1283188)

Zitat:

Zitat von Lemmy (Beitrag 1283186)

Fang keinen Blödsinn an wie "Dann lege eine Tabelle_x an" wenn einen voll ist.. vergiss das ganz schnell wieder...

Bitte mach ein Schild und vermarkte es. Ich bin der erste, der es kauft und vielen der DB-Spezialisten die ich kenne für die Rübe nagelt! Danke.

Ich weiß ja nicht wen Du kennst, aber DB-Spezialisten sind das nicht!

Gruß
K-H

[Der schöne Günther]

Zitat:

Zitat von joachimd (Beitrag 1283215)

Ich habe in meinen 15 Jahren als ADS Betreuer noch keinen getroffen, der auch nur annähernd an diese Grenze kam. das heißt jetzt nicht, dass es das nicht gibt - aber unter unseren Kunden eben bisher nicht.

Glaube ich. Aber wenn ich für das Projekt einen anderen Server nehme werde ich diese Grenze ja natürlich auch nicht erreichen ;-)

Zitat:

Zitat von Dejan Vu (Beitrag 1283214)

aber beim Aufbau der Fabrik und in den ersten 2-3 Jahren hat man sich Daten der letzten 6-10 Monate durchaus angeschaut und das waren dann eben so viele.

Ganz genau. Mich würden die Daten auch nicht interessieren aber es gibt Leute, die wollen sie haben.

[p80286]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1283204)

Zitat:

Zitat von Dejan Vu (Beitrag 1283197)

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:

Zitat von mkinzler (Beitrag 1283227)

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.