Danke an Alle...
@Union: interessante Ansätze.
Zitat:
Wie groß wird diese ID maximal?
unbekannt. Vermute 6 stellig. Für einen SmallInt zu groß. Außerdem benötige ich später sowohl den Timestamp als auch den Parameter im
SQL bei den Auswertungen. Da bleibt nicht mehr viel übrig.
Zitat:
Wenn man die Basis des Timestamp (den Offset 0) in die nähere Vergangenheit setzt, kommt man auch mit weniger Platz aus.
Du meinst so nah, daß der Rest in einen SmallInt paßt? Geht nicht.
Im Beispiel: letzter DS = 1398999942 erster = 1381299573
Zitat:
Sind das wirklich individuelle Werte oder sind das Fixtexte?
Kann sowohl ein Zeichen ('+'), ein digitaler Wert ('0'/'1') oder ein analoger Wert ('-999.99' bis '999.99') sein. In der ersten Version waren das sogar getrennte Felder. Varchar(10) soll das absolute Maximum darstellen. Der Platzbedarf sollte ja nur so groß sein wie die Daten oder? Der Timestamp könnte auch ein TDateTime sein. Was braucht weniger Platz?
Zitat:
Ist das mit dem Platz im Jahr 2014 wirklich ein Problem?
Da macht es die Masse über die Dauer. Im Maximum könnten 500 Geräte für 10 Jahre gespeichert werden. (rechnerisch derzeit ca. 11 TB) Im Normalfall reden wir über 1 - 3 Geräte. Da ist das natürlich kein Problem...
PS: Es geht um Temperaturaufzeichnungen in der Lebensmittelbranche und Pharmaciebranche. Die genauen Speicherzeiträumen per Gesetzt sind mir unbekannt. Da aber das Finanzamt 10 Jahre Aufbewahrung hat ging ich mal ebenso davon aus.
Rein theoretisch hat das Gerät einen Speicherzyklus von 1-3 Jahren je nach Auflösung. Dann werden die ersten Daten wieder überschrieben. Per Gesetz sind die so zugelassen und man könnte die
DB Speicherung auch darauf begrenzen. Ich will aber einen Mehrwert für den Kunden. Quasi das was die Hardware nicht leistet.
Zitat:
Übersehen nicht, nur nicht explizit drauf eingegangen. Aufgrund der Beschreibung bin ich davon ausgegangen, dass die Daten einmal importiert werden um dann für Auswertungen vorgehalten werden bzw. bei Aktualisierungen die Daten als "Masseninserts" rein kommen und nicht individuell von den Anwendern geändert werden können / sollen. Und hier würde ich (wenn die
DB-Größe wirklich ein Thema sein sollte) ggf. die beschrieben Dinge anwenden.
Unter 2.5 soll es ja auch möglich sein über StoredProcedures auf anderen DBs zugreifen zu können. Somit könnten diese Gerätedaten in eigene, ggf. auch als Read-OnlyDBs ausgelagert werden und die Pages voll gemacht werden.
Im Prinzip sind die Daten als ReadOnly zu betrachten und werden nur für Auswertungen etc. vorgehalten. Um aber die Größe nicht bis ins unendliche wachsen zu lassen sollen die Ältesten nach einem Zeitraum X entfernt werden.