Hallo Harald,
danke für Deine schnelle Antwort!
Admin Service Limited
Zwei Nachfragen:
1.) Gibt es noch Details (z.B. zu den Messpunkten)? Dies würde z.B. eine Messpunkt Tabelle erfordern. Ansonsten reicht eine Tabelle für die Werte.
Beispiel der Messpunkte, bzw. deren Werte:
"arrayMesspunkt_WertA_1_44":[
[3996600, ... 4030793,4030807], (Array der SummenWerte alle 10 Minuten, von 1-108 <-> 5:00-23:00)
[3990900, ... 4025229,4025667],
...
[3990900, ... 4025124,4025253]
](Array der Messpunkte von 1-44)
Es gibt 5 Wertetypen pro Messpunkt die abgefragt werden können, zB: Wert A-E. In einer Tabelle währen das wohl dann Spalten?!
Admin Service Limited
2.) Mich stört das Aufsummieren. Besser wäre es wenn man die Zwischenwerte hätte. Das Bilden der Summe kann man der Datenbank überlassen - das kann die ganz gut. Mit den Zwischenwerten könntest Du dann nämlich auch eine schöne Entwicklung der Werte als Chart ausgeben.
Ja, das Aufsummieren stört mich auch, leider kommen die Daten derzeit von einer schon bestehenden Schnittstelle.
Ich möchte aber eigene Messwerte aus eigenen Messpunkten hinzufügen, daher möchte ich nur bedingt auf die aktuelle Schnittstelle Rücksicht nehmen.
Es ist zwar eine Krücke, aber wenn die Daten alle 10 Minuten in der Datenbank landen, werde ich wohl die Zwischenwerte gleich berechnen und mit diesen weiterarbeiten.
Die Daten werden vornehmlich in Charts ausgegeben und verglichen etc. Ich berechne die Werte derzeit recht (Rechenpower)aufwändig in Echtzeit.
Admin Service Limited
So aus der Hüfte:
Tabelle messpunkt
==============
_id integer primary key
name text
aktiv char(1) --> J/N (ein Messpunkt wird nie gelöscht, sonst verliert man bei on delete cascade die zugehörigen Werte)
... weitere Details
...ok, Messpunkte werden nur deaktiviert aber nie gelöscht, klar sonst sind die Daten ohne Bezug.
Admin Service Limited
Tabelle messwert
==============
messpunkt integer foreign key references messpunkt(_id)
timestamp integer --> alternativ (jahr integer, monat integer, tag integer, ...)
messwert real --> am Besten nur die Differenz zwischen dem vorherigen Wert und dem aktuellen)
... weitere Details
Index
====
1.) messpunkt
2.) timestamp
* Auf zusammengesetzte Indexe verzichte ich bei den Android Devices. Die Performance geht dann etwas runter aber es spart Internal Memory - und das ist meist knapp bemessen. Es sei denn die DB wird auf der SD-Karte angelegt (die ist aber meist langsamer).
Derzeit läuft das ganze noch auf einem embeded System bzw. in einer VM. aber das Ziel ist alles auf Android Tabletts zu bringen. Die Charts werden als SVG berechnet.
Admin Service Limited
* In den Timestamp kommen die millis. Wenn Du dann aber nach einem Monat suchst muss die DB immer transformieren. In dem Fall würde ich schon fast zum Aufklappen der Datumsstruktur tendieren. Dann muss natürlich auch der Index aufgeklappt werden:
1) messpunkt
2.) jahr
3.) monat (nur wenn es eine Suche nach Monat ohne Tag und ohne Messpunkt gibt).
Ok, jetzt stosse ich an die Grenzen meines Halbwissens...
Aufklappen: statt dem Timestamp in millis lieber Jahr/Monat/Tag als einzelne Index-Spalten, sonst muss ich ewig den Timestamp auswerten?!
Soweit glaube ich verstanden.
zu 3. ja, es gibt die Suche nach Monat ohne Tag, aber ohne Messpunkt? Dann krieg ich ja keine Werte, oder?!
Da ist aber der Punkt an dem ich nicht verstehe wie ich die IndexTabellen anlege (oder macht das die DB über autoindex?) und dann, vor allem möglichst hochperformant meine SQL-Abfragen schreibe.
Auf was muss ich achten, wie beziehe ich die Indizes richtig in meine SQL-Abfragen ein?
Die am meisten gemachte Abfrage sind Tageswerte in der Historie, wie im obigen Beispiel: "arrayMesspunkt_WertA_1_44".
Da ich noch nicht ganz klar komme mit den Indexabfragen, fehlt mir noch die richtige Strategie für die Tabellenstruktur, ich versuche es trotzdem:
1. Tabelle Messpunkt: wie von Dir beschrieben.
2. Tabelle Messwert: In einem Messpunkt-Datensatz/Zeile finden sich dann die Indizes ( Messpunkt, Jahr, Monat, Tag) plus die Messwerte real (Differenz) A-E
Macht es Sinn für jedes Jahr eine eigene Messwert-Tabelle zu erzeugen? Es sind rund 40.000 - 1.7Mio Zeilen mit 200.000 - 8.8Mio Messwerten Pro Jahr.
Oder wie soll ich mit der (Un-)Menge Datenbank-Technisch umgehen?
Admin Service Limited
Mit diesen Angaben kannst Du dann alles machen. Nach Messpunkten gruppieren, nach Jahren, Monaten - alles was das Herz begehrt.
Wenn Du die Aufsummierungen in den Messwerten hast wird es unter Umständen "ätzend". Der Tages-, Monats- oder Jahres-Höchstwert ist dann immer nur der höchste Timetamp dieses Bereiches (und somit nur eine Zeile) aber die Entwicklung über einen Tag, Monat, Jahr erfordert das Joinen mit sich selbst. Also wenn es eben geht nimm den Zwischenwert auf und nicht die Aufsummierung.
Ich werde die Zwischenwerte beim speichern berechnen, mal sehen, evtl. geht das ja über einen TRIGGER.
Was meinst Du, sollte ich die Aufsummierung dann verwerfen, oder mit abspeichern?
Admin Service Limited
Was war noch mal Deine Frage ;-)
Darf ich Dir noch ein paar Fragen stellen? ;-)
Admin Service Limited
Du hast mir schon mal den Weg gezeigt.
Vielen Dank
Helmut
— geändert am 01.06.2011, 12:08:56
Empfohlener redaktioneller Inhalt
Mit Deiner Zustimmung wird hier ein externer Inhalt geladen.
Mit Klick auf den oben stehenden Button erklärst Du Dich damit einverstanden, dass Dir externe Inhalte angezeigt werden dürfen. Dabei können personenbezogene Daten an Drittanbieter übermittelt werden. Mehr Infos dazu findest Du in unserer Datenschutzerklärung.