leider klappt das irgendwie nicht so richtig. In meinem Fall habe ich 2 Tabellen mit Datumsanzeige.
Von einem Tag will ich die Summe von einer Spalte haben.
SELECT
sum("Heizung2"."Temp")+sum("Heizung1"."Temp"),
"Heizung1".date1
FROM
public."Heizung1" LEFT JOIN public."Heizung2" ON "Heizung1".date = "Heizung2".date
GROUP BY
"Heizung1".date,
"Heizung1"."Temp"
Leider kommt als Summe nur Mist raus! Die Zahlen sind völlig willkürlich gewählt und die
Logik erstmal aussen vor gelassen! Ich muss erstmal verstehen, was Sql genau macht!
Wo habe ich den fehler? kann mir jemand erklären, warum da nur Mist rauskommt?
Als Summe kommt meist mehr als die doppelte Summe raus!
test=*# select * from h1;
id | temp | datum
----+------+------------
1 | 1 | 2011-01-01
2 | 1 | 2011-01-01
3 | 1 | 2011-01-02
(3 rows)
Time: 0,245 ms
test=*# select * from h2;
id | temp | datum
----+------+------------
1 | 1 | 2011-01-01
2 | 1 | 2011-01-01
3 | 1 | 2011-01-02
(3 rows)
Time: 0,248 ms
test=*# select h1.*, h2.* from h1 left join h2 on (h1.datum=h2.datum);
id | temp | datum | id | temp | datum
----+------+------------+----+------+------------
1 | 1 | 2011-01-01 | 1 | 1 | 2011-01-01
1 | 1 | 2011-01-01 | 2 | 1 | 2011-01-01
2 | 1 | 2011-01-01 | 1 | 1 | 2011-01-01
2 | 1 | 2011-01-01 | 2 | 1 | 2011-01-01
3 | 1 | 2011-01-02 | 3 | 1 | 2011-01-02
(5 rows)
Vielleicht überdenkst Du einfach mal was Du willst. Ein JOIN über das Datum führt recht sicher nicht zum Ziel. Allerdings hab ich auch nicht recht verstanden, was Du genau willst.
Wenn ich mir das genauer betrachte, dann merke ich, das ist JOIN
total falsch verstehe. Jetzt weiß ich auch, wie meine Ergebnisse
zustande kommen. Danke! Schon mal kapiert. Join vergleicht alle
ID mit Temp und listet diese auf. Wie kann ich jetzt die Gesamt
summe von Temp berechnen? Hier wäre join schon mal fehl am Platz,
richtig?
Und übrigens, dieses h1 und ha2 will mein postgre einfach nicht
machen, da die Tabelle nicht existiert!?
test=# select datum, sum(temp) from (select temp, datum from h1 union all select temp, datum from h2) foo group by datum;
datum | sum
------------+-----
2011-01-01 | 4
2011-01-02 | 2
(2 rows)
Als wirklich sinnvoll halte ich dies zwar nicht, aber scheinbar willst Du das so. Ach ja: meine Tabellen heißen bei mir anders als bei Dir. Das SQL für Deine Tabellenname anzupassen überlasse ich Dir mal zur Übung
Man will nur die Gesamtsumme aller Temperaturen von verschiedenen Heizungen nur von einem Tag. Von welchem Raum und so weiter spielt keine Rolle. Das ganze soll am Ende über einen Report nach einem Monat in einem Diagramm dargestellt werden.
Eigentlich genial wie du das gemacht hast, das macht Sinn und ist mir nicht in den Sinn gekommen Das schafft man sicher durch Erfahrungen. Vielen Dank Andreas
Ich musst erstmal überlegen, was genau du hören willst. Ich erkläre das mal so. Es besteht bereits eine Datenbank, in die Datenbank fließen verschiedene Messwerte von verschiedenen Heizungen ein. Jede Heizung hat eine Tabelle zugewiesen bekommen. Mein Problem war nur ein Bruchteil für Testzwecke geeignet, da es zuviele Messwerte gibt. Verstehst du jetzt?
Moment mal, ihr habt pro Messstelle eine neue Tabelle?
Nun, finde ich damit ab - wie akretschmer gesagt hat - dass das sehr langsam wird. Oder das ihr doch überlegt, ob man da etwas ändern kann.
Also ich hab das ganze jetzt mal übernommen, dementsprechend angepasst und ausgetestet! Irgendwas mache ich falsch. Sieht
so aus, das ich die ganzen Grundlagen nochmal anschauen sollte, bevor ich mich in das Projekt
reinstürze.
Jetzt lese ich desöfteren was von Skalierung. Was meint ihr damit? Vermutlich hat das mit den zu großen
Datenmenge zu tun oder?
Mit ‘Skalierung’ meinen wir, daß Dein DB-Schema und Deine Anwendung nicht dafür ausgelegt ist, daß Euer System wachsen kann. Immer, wenn eine Messstelle dazu kommt, müßt ihr eine neue Tabelle anlegen (DB-Schema) und das SQL ändern (Anwendung).
Und in Oberhausen ist die PGCONF.DE, am 11.11.2011. Dort könntest Du an einem Tag so viel zu PG lernen wie in 10 Jahren mitlesen hier. So in etwa.
Ok, das mit Oberhausen sollte sich lohnen. Denn ich merke gerade, das die Abfrage aufgrund riesiger Datenmenge (von heute für eine Heizung jetzt schon 3000 Datensätze) sehr sehr langsam ist. Grausam
Welches Programm würdest du mir als Anfänger raten, um meinen “Auftragsgebern” mit meinen Überzeugungskünsten zu überreden das Design zu ändern
Ist es auch wirklich so, das DB-Design so ändern, das die Abfrage viel schneller abläuft? Den anscheinend wird alle 5 min gemessen…
Die letzte Frage für heute. Der Code funzt leider nicht mit Uhrzeitangaben. Die Zeit-Spalte ist mit timestamp with time zone deklariert. Wie kriege ich es dennoch hin den Tag auszurechnen?
Konkret meine ich damit: mein Arbeitgeber hat eine PostgreSQL Version, die auf sehr große Datenmengen und Skalierbarkeit ausgelegt ist.
Aber das wird bei dir nicht funktionieren - dazu ist dein Datenmodell zu äh bescheiden. Sorry.
akretschmer hat Recht: komm nach Oberhausen, bring deinen Auftraggeber mit.