Otimierung SQL Abfrage oder Logik

[TBx]

Korrekt wäre es, den ersten Wert zu ermitteln, denn den hat Du ja definitiv nicht (er entspricht der letzten Datenänderung vor dem Zeitraum. Der letzte Wert entspricht dem letzten Wert aus dem Select.
Die Ermittelung der Werte kannst Du Dir natürlich sparen, wenn zufällig zu Beginn und Ende ein Wert vorhanden ist.

[haentschman]

Danke Allen...:P

Zitat:

Ich verstehe eher nicht, warum er die Werte nicht einfach manuell ergänzt.

Hab ich ja jetzt. Die SQL Abfragen waren wahrscheinlich Koffeinmangel geschuldet. :stupid: Oder man sieht den Wald vor lauter Bäumen nicht. Die meisten Ideen kommen bei Aufschreiben des Problems...:thumb:

Zitat:

Korrekt wäre es, den ersten Wert zu ermitteln, denn den hat Du ja definitiv nicht (er entspricht der letzten Datenänderung vor dem Zeitraum.

Richtig, das wäre korrekt. (letzter VOR dem gewählen Zeitraum) So hatte ich es ja. Das brachte für jede Serie ein zusätzliches SQL... den Overhead. Ich wahnsinniger hatte sogar am Ende per SQL abgefragt... :wall: :P

[HeZa]

Zu erst mal möchte ich Bug zustimmen: Wenn nicht gemessen wird zeig auch nichts an. Der Vergleich mit dem EKG hinkt. Denn das EKG misst auch wenn es pieep macht, nur das der Wert eben 0 ist. Deine waagerechten farbigen Linien stellen aber ein Wert da, nur dass dieser gar nicht gemessen wurde, ist dann also eigentlich eine Falschaussage.

Zu den fehlenden Werten. Probier mal folgendes: Leg ein Tabelle mit den Datum aller Tage über einen Zeitraum von, sagen wir mal 10 Jahren (macht gerade mal ca. 36500 Datensätze) an:

Code:

create table T_DATUM (
  DATUM date not null,
  UNIX_START int not null,
  UNIX_END int not null,
  primary key DATUM
);

Dann die Tabelle entsprechend füllen und und baue dein SELECR um:

Code:

select
  rd.F_PARAMETER_ID, 
  -- damit auch ein Timestamp zurückgegeben wird, wenn keine Daten da sind
  case when rd.F_TIMESTAMP_UNIX = null then d.UNIX_START else rd.F_TIMESTAMP_UNIX end as F_TIMESTAMP_UNIX, 
  rd.F_POWER_STATE, 
  rd.F_VALUE, 
  mt.F_TYPE_ID
from
  T_DATUM d
  left outer join T_RECORD_DATA rd ON rd.F_TIMESTAMP_UNIX between d.UNIX_START and d.UNIX_END
  inner join T_DEVICE_PARAMETERS dp on dp.ID = rd.F_PARAMETER_ID
  inner join T_MEASURE_TYPES mt on mt.ID = dp.F_MEASURE_TYPE_ID
where
  rd.F_PARAMETER_ID = 1060 and d.DATUM between <startzeitpunkt> and <endzeitpunkt> -- jetzt aber als DATE formatiert
order by
  rd.F_TIMESTAMP_UNIX desc

Alles ungetestet (habe keine Firebord DB.

[haentschman]

Zitat:

Der Vergleich mit dem EKG hinkt. Denn das EKG misst auch wenn es pieep macht, nur das der Wert eben 0 ist.

:zwinker:

Zitat:

Wenn nicht gemessen wird zeig auch nichts an.

Ich werde das Ganze mal aussitzen und hören wie die Anwender, die die Grafiken beurteilen müssen, darüber denken. Die "nicht gemessenden" Werte auf die 0 Linie runter zu ziehen ist kein Problem. Ggf. Kann man das als Anzeigeeinstellung implementieren und vom User einstellen lassen... 8-)

[HeZa]

Der Anwender ist König. :-)

Trotzdem, die Werte auf 0 runterziehen wäre für mich keine Lösung. Denn die Werte sind nicht 0, das System kennt diese Werte nicht.

Wenn ich dich frage wieviel Geld hattest du gestern in deiner Brieftasche und du antwortest 0 Euro ist das etwas komplett anderes als wenn du sagst, weiß ich nicht.

[haentschman]

:P Die 0 Linie ist ja die X-Achse und damit sind die Linien quasi nicht sichtbar...