Otimierung SQL Abfrage oder Logik

[haentschman]

Danke für deine Anteilnahme...

Zitat:

Oder habe ich das Problem komplett falsch verstanden?

Ja leider...aber nicht schlimm. Den Erklärbär hab ich schon wegen Hilfe kontaktiert...

Das Problem ist nicht die Datenbank sondern die Anzeige bei Anzeigezeitraum größer als Datenzeitraum der vorhandenen Daten. Um diese waagerechten Striche der Serien (Anfang und Ende) zu bekommen benötigt man einen Datenpunkt am Anfang Anzeigezeitraum und Ende Anzeigezeitraum. Diese Werte hatte ich aus der DB ermittelt. Auch wenn die einzelne Anweisung schnell war brachte die Summe der Abfragen einen blöden Overhead. Das habe ich jetzt so gelöst, das ich schon geladene Daten verwende als immer die Werte neu zu ermitteln.

[HeZa]

Zitat von haentschman:

Das Problem ist nicht die Datenbank sondern die Anzeige bei Anzeigezeitraum größer als Datenzeitraum der vorhandenen Daten. Um diese waagerechten Striche der Serien (Anfang und Ende) zu bekommen benötigt man einen Datenpunkt am Anfang Anzeigezeitraum und Ende Anzeigezeitraum. Diese Werte hatte ich aus der DB ermittelt. Auch wenn die einzelne Anweisung schnell war brachte die Summe der Abfragen einen blöden Overhead.

Das Problem ist (oder war) also die Skalierung der Anzeige?

Was ich immer noch nicht verstehe, wieso kommst du nicht mit einem einzigen SELECT-Statement aus:

Code:

select 
  D.F_PARAMETER_ID, D.F_TIMESTAMP_UNIX, D.F_POWER_STATE, D.F_VALUE, T.F_TYPE_ID 
from 
  T_RECORD_DATA D
  join T_DEVICE_PARAMETERS P on P.ID = D.F_PARAMETER_ID
  join T_MEASURE_TYPES T on T.ID = P.F_MEASURE_TYPE_ID
where 
  D.F_PARAMETER_ID = 1060 and D.F_TIMESTAMP_UNIX between <startzeitpunkt> and <endzeitpunkt>
order by 
  F_TIMESTAMP_UNIX desc

<startzeitpunkt> und <endzeitpunkt> würden in diesem Fall dadurch bestimmt werden, welchen Zeitraum du anzeigen möchtest.

Ich weiß jetzt nicht, ob sich das Thema für dich erledigt hat, ansonsten hätte ich noch ein paar Fragen:

• Zeichnest du das Diagram selbst?
• Wann bzw. warum kommt es zu einer senkrechten gestrichelten Linie?
• Bedeuten die farbigen waagerechten Linien, das der Wert gleich geblieben ist, oder das keine Messung erfolgte?

[haentschman]

Danke für deine Zeit...

Zitat:

Ich weiß jetzt nicht, ob sich das Thema für dich erledigt hat, ansonsten hätte ich noch ein paar Fragen:

...prinzipiell ja. Aber ich beantworte dir das gern.

Zitat:

Was ich immer noch nicht verstehe, wieso kommst du nicht mit einem einzigen SELECT-Statement aus:

Für das Laden der Daten des Zeitraumes ist ein select Statement zuständig.

Zitat:

Zeichnest du das Diagram selbst?

Nein. TChart.

Zitat:

Bedeuten die farbigen waagerechten Linien, das der Wert gleich geblieben ist, oder das keine Messung erfolgte?

Die waagerechte Linie bedeutet (soll bedeuten) das keine Werte gemessen wurden. Quasi wie auf dem EKG... piiieeeep:

Zitat:

Wann bzw. warum kommt es zu einer senkrechten gestrichelten Linie?

Die berechnet TChart aus den vorliegen Daten anhand einiger "Vorgaben". Das läßt man in der Regel auf Automatik, sonst kommen manchmal komische Bilder raus.

Nochmal ein Beispiel:
* Chart soll angezeigt werden vom 1. bis 31.
Ein select Statement lädt die Daten vom 1. bis 31. (Daten vorhanden: 11.,12.,13.)
Jetzt würde TChart eine Grafik skalieren vom 11. - 13. Das ist ein Modus den ich dem Nutzer zur Verfügung stelle.
Der 2. "Modus" soll den gesamten Zeitraum (1. - 31.) auf der X-Achse darstellen und die Daten (11.,12.,13.) in der Mitte. Um die waagerechte Linie darzustellen benötigt TChart einen Wert für den 1. und einen Wert für den 31. Diese habe ich mir per seperate SQL geholt. Das machte dann 3 SQL Anfragen per Serie. Die 2 zusätzlichen brachten den zeitlichen Overhead der mir nicht gefiel. Das war die eigentliche Frage...
Die 2 zusätzlichen SQL Anfragen habe ich jetzt gespart und die Werte für den 1. und 31. aus den vorhandenen Daten generiert. Nur wenn keine Daten geladen wurden muß ich nun 1x den letzten Wert vor dem gewählen Zeitraum holen um eine Linie darzustellen.

[BUG]

Zitat von HeZa:

• Wann bzw. warum kommt es zu einer senkrechten gestrichelten Linie?
• Bedeuten die farbigen waagerechten Linien, das der Wert gleich geblieben ist, oder das keine Messung erfolgte?

Das ist ein Problem an der Sache. Auch wenn es nicht so schön aussieht, sollte man fehlende Daten nicht zeichnen oder zumindest anders kenntlich machen (Strichellinie/graue Linie).

Dein anfängliches Problem kann ich nachvollziehen: Ich möchte vielleicht den letzten Wert der letzten Messserie (z.B. am Tag davor) als Referenz haben um zu gucken, wie sich der erste Wert davon unterscheidet. Da liegt vielleicht ein Ansatz zum Optimieren: wenn der letzte Wert zu lange her ist, interessiert der mich vielleicht auch gar nicht mehr.

Aber sich einfach einen Wert auszusuchen um Lücken zu füllen ist vielleicht nicht die beste Idee.

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

[jobo]

Ich hab es so verstanden, dass er einen fixen Zeitraum anzeigen will, in der Gradikkomponente (automatisch) definiert über minimale und maximale Werte im Zeitstrahl. Normalerweise erhält er diese Werte auch, mittels einer Abfrage wie Deiner, weil kleinschrittige Messwerte vorliegen.
Bei Anlagenausfall fehlen ab Messwerte für größere Zeiträume, was zu häßlichen "Kurven" führt.
Er braucht also für die Diagramme notfalls Fakewerte, die garantiert Anfang und Ende setzen, also Wertepaare Startzeitpunkt;0, Endzeitpunkt;0, sowie ZeitpunktErsterVorhandeneMeßwert-Schrittweite;0, ZeitpunktLetzterVorhandenerMeßwert+Schrittweite;0
um mit angemessener Flanke vom Nullpunkt einzusteigen.

Ich verstehe eher nicht, warum er die Werte nicht einfach manuell ergänzt. Zumindest klingt die Beschreibung nicht so, als ob die Chartkomponente direkt die SQL Werte schluckt, sondern aus einer Werteliste gefüttert wird, die einfach zu manipulieren wäre.

rote Schranke: Hab jetzt die Antworten noch nicht gelesen

[haentschman]

Danke Allen...

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. Oder man sieht den Wald vor lauter Bäumen nicht. Die meisten Ideen kommen bei Aufschreiben des Problems...

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

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

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

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