Kombinierte Abfrage einer Messerttabelle

[PR_VT]

Hallo zusammen,

ich stehe vor einem Problem mit einer SQL-Abfrage. Ich habe eine Messdatentabelle mit Messwerten und Grenzwerten. Nun möchte ich alle Datensätze anzeigen, die den Grenzwert (Datum im jeweiligen Datensatz) überschritten haben. Das müsste doch irgendwie mit einer kombinierten Abfrage gehen, oder?

SELECT * FROM Messwerttabelle WHERE Messwert > .....

Mein Problem ist, dass jeder Datensatz für sich betrachtet werden muss, da sie die Grenzwerte von Datensatz zu Datensatz unterscheiden können.

Daten:
Messwert Grenzwert
10 9
11 11
12 9
13 9

Soll-Ergebnis:
10 9
12 9
13 9

Vielen Dank vorab schonmal für Eure Hilfe!

Viele Grüße

PR_VT

 

[dabadepdu]

where messwert > grenzwert

 

[BerndB]

Du solltest eventuell einmal deine Datenbankstruktur überprüfen. Es scheint keine besonders gute Lösung zu sein den Grenzwert mit in jede Zeile zu legen. Dadurch wird bei einer SELECT Abfrage notwendig das MySQL immer alle Zeilen der Tabelle liest, da die Bewertung Messwert > Grenzwert erst dann festgestellt werden kann und somit auch KEIN INDEX genutzt wird.
Ich kenne zwar die Größe deiner Tabelle nicht, aber der Name "Messwerttabelle" hört sich schon so an als ob diese sehr schnell wachsen könne und somit wird deine Abfrage immer langsamer je mehr Messwerte enthalten sind.

 

[akretschmer]

Dadurch wird bei einer SELECT Abfrage notwendig das MySQL immer alle Zeilen der Tabelle liest, da die Bewertung Messwert > Grenzwert erst dann festgestellt werden kann und somit auch KEIN INDEX genutzt wird.

Das ist in der Tat eine Einschränkung - bei MySQL.

edb=# create table messwerte(messwert int, grenzwert int);
CREATE TABLE
edb=*# create index idx_werte on messwerte (messwert, grenzwert) where (messwert > grenzwert);
CREATE INDEX
edb=*# insert into messwerte select (random()*20)::int, (random()*15)::int from generate_series(1,10000) s;
INSERT 0 10000
edb=*# explain analyse select messwert, grenzwert from messwerte where messwert > grenzwert;
                                                       QUERY PLAN                                                        
-------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on messwerte  (cost=41.78..128.44 rows=3333 width=8) (actual time=0.447..2.665 rows=5934 loops=1)
   Recheck Cond: (messwert > grenzwert)
   Heap Blocks: exact=45
   ->  Bitmap Index Scan on idx_werte  (cost=0.00..40.95 rows=3333 width=0) (actual time=0.407..0.408 rows=5934 loops=1)
 Planning Time: 0.251 ms
 Execution Time: 3.554 ms
(6 rows)

edb=*#

Wie zu sehen: ich habe einen passenden Index für diese Condition und dieser wird auch genutzt. Ist halt aber kein MySQL, das kann das nicht.

 

[dabadepdu]

Nichts gegen ein Lob von Postgres.

Aber Messwertanalyse ist m.E. ein Thema für sich.

Im Eingangspost war ja auch die Rede von einem Datum, das aber im Beispiel gar nicht vorkommt. Das würde man sehr wahrscheinlich eher indizieren und hätte dann einen Rangescan je nach abgefragtem Datum.

Ansonsten je nach Bedarf, Einsatzbereich:
- Bei der Erfassung Messfehler direkt rauswerfen
- oder separat erfassen, falls evtl./jemals benötigt
- Grenzwerte separat erfassen, je nach Datum, Sensortyp, ..

Ich kann mir grad auch nicht vorstellen, dass wirklich jede Messung einen anderen Grenzwert hat. Viel wahrscheinlicher könnte es ein (berechneter bzw. dynamischer) Schwellwert sein, z.B. je nach Temperatur, Licht/Sonnenverhältnissen, ..

Alle späteren Analyse Zusammenhänge, also Abfragebedingungen als Funktionalen Index einzubauen, ist sicher flott, aber neben der Fleiß – auch eine Platzfrage, wenn hinreichend viele Messdaten reinkommen.

 

[akretschmer]

Nichts gegen ein Lob von Postgres.

Natürlich ;-)

Falls das eine schnell wachsende, faktisch append-only Tabelle mit einem stetig wachsenden Timestamp ist (Zeitpunkt des Messwertes) und Abfragen sich auf Zeitbereiche einschränken, käme übrigens auch hier ein PostgreSQL-Feature in den Sinn: BRIN-Indexe.

Und wenn es wirklich sehr viele Datensätze sind, und vielleicht auch unterschiedliche Mess-Stationen im Einsatz sind, und Daten nach bestimmter Zeit zu löschen sind (weil nach X Monaten nicht mehr relevant): Partitioning (nach Zeit, nach Sensor)

 

[PR_VT]

where messwert > grenzwert

So einfach

 

[PR_VT]

Ich meinte mit Datum nicht das Datum an sich sondern einen einzelnen Wert im Datensath. War missverständlich...

 

[PR_VT]

Danke für die Optimierungshinweise! Die Messgrenzen ändern sich manchmal. Dann werde ich das anders organisieren.

Danke an alle und schöne Weihnachten

Gruß

PR_VT