Bezüglich der benötigten HD würde ich den Nettoverbrauch, also die reinen Nutzdaten mit dem Faktor 3-4 multiplizieren, da Du hochredundante Indexe(60-80% der Daten sind dort nochmals vorhanden) und Aggregationstabellen verwendest etc.
Betrachtungen der Art "immer Donnerstags zwischen 7:00 und 12:00" wird es, laut nun mehrmonatig erstelltem Anforderungsprofil des Kunden (durch uns begleitet), nicht geben.
Das war nur ein Beispiel, um die Flexibilität eines RDBMS ggü. einem handgebissenen Dateiformates zu belegen. Ich denke, das wird kommen, denn beim Datamining und dem Suchen nach Ursachen spielen auch Tageszeiten, Wochentage eine Rolle (können! könnten!). Aber da die Spec das nicht vorsieht, ist es ok. Ich würde es in der Hinterhand halten und eventuell den Timestamp doppelt abbilden: vDateTime, vDate, vTime. Das nachzurüsten geht natürlich auch, würde aber ein einmalig stundenlanges rumrödeln bedeuten. Aber gut: Das würde bezahlt werden.
Zitat:
Excel spielt keine Rolle.
Wichtig ist: Da du hier mit einem Standard-RDBMS arbeitest, sorge nur für einen
Ole-
DB provider (
ODBC mit
ADO geht auch).
Zitat:
"Materialized Views" erscheinen mir als ungeeignet. Beziehungsweise mache ich ja mit meinen Aggregat-Tabellen etwas sehr ähnliches, und das "Gewürgel" dies auf die verlinkte Art in reinem
SQL auf
MySQL abzubilden... da gefällt mir meines besser. Zumal es ziemlich einfach auch für Pflegeläufe nutzbar ist, sollte es dort wirklich mal Probleme geben.
Ich kenne die Tools für
mySQL nicht, aber ich finde einen zeitgesteuerten
SQL-Job wesentlich besser, weil das alles in einer Umgebung läuft, die alles schon eingebaut hat: Wiederholung bei Fail, E-Mail-Benachichtigung im Fehlerfall etc. Logging ist auch vorbildlich: Wozu also das
Rad neu erfinden... Schau mal, ob Du dich mit professionellen ETL/cron-Tools für
mySQL anfreunden kannst.
Bezüglich deiner Auswertetools, die Du alle selbst schreiben willst, würde ich auch mal prüfen, ob es etwas derartiges nicht gibt. Natürlich macht Programmieren Spaß, aber wenn es etwas Fertiges gibt... Wieso nicht? Oder zumindest Denkansätze besorgen.
Zum Abschluss noch meine persönliche Meinung:
Ich würde mir noch überlegen, ob ein
SQL-Server nicht eher in Frage kommt, zumal Du dort alles hast, was Du brauchst: SSIS um die Jobs zu definieren, SSAS, um OLAP-Cubes zu entwerfen und zeitgesteuert zu füllen (Eine noch bessere Alternative als die handgebissenen Aggregattabellen), SSRS um Reports zu generieren etc.
Je weniger ich selbst programmieren muss, desto besser: Denn ich werde mir die gleichen blutigen Nase an genau der gleichen fiesen Ecke holen, wie tausende Programmierer vor mir: Nur warum soll ich mir das antun?
Einzeln aufgebaute Indizes werden durch die Optimizer idR besser nach Bedarf zusammengesetzt
Du kannst Indexe doch nicht zusammensetzen? Ein Index auf 'B' bringt dir doch gar nichts, wenn Du nach 'A' und 'B' suchst, und schon einen Index 'A' verwendest. Wie soll das denn gehen? Was richtig ist: Mit einzelnen Indexen kannst Du unterschiedlichen Queries idR besser begegnen, aber wenn es hier eh nur ein
Query-Pattern gibt, nimmt man besser auch nur einen Index.
Zitat:
Letztlich ist das Indexthema aber sekundär, weil man es unabhängig von der Logik mit ein paar Handgriffen variieren und testen kann, notfalls sogar auf einem Produktivsystem.
Da wird der Kunde aber ziemlich kotzen, wenn Du in seinem Produktivsystem mit Indexen experimentierst: Schließlich ist das System doch ziemlich ausgelastet (und die Tabelle gelockt), wenn Du mal den Kombi-Index über die TB an Daten neu erstellen willst. Da würden dann alle Messstationen meckern, weil der Server nicht erreichbar ist => keine gute Idee.
Lieber vorher Testdaten erzeugen (10 Jahre: 150.000 x 365 x 10= 547.500.000), damit rumspielen und ein Gefühl für die Queries bekommen.
Aber sekundär ist das Thema wirklich.
..Wenn du hier, die Berechnung des max-/durschnittswertes innerhalb des kleinsten Intervalls in der
DB realsieren möchtest, sehe ich hier schon mal ein Problem
Welches?
Zitat:
Auch taugt meist ein Index der aus einen Double besteht nichts.
Natürlich taugt der was: Beim Aggregieren nimmt das RDBMS nämlich diesen Wert und muss den Datensatz nicht laden. *Suchen* nach Messwerten wird man nie
Zitat:
Wünsche schon mal viel Glück.
Glück wird hier nicht benötigt. Das ist eine Standardanforderung an eine Messdatenerfassung. Das ist, wie man so schön sagt: 'No big deal'.