Summen aus 2 Tabellen gegenüberstellen

[HRGS85]

Hi zusammen,

ich habe eine Sales Tabelle und eine Retour Tabelle. In beiden stehen Artikelnummern und die Anzahl Sales bzw die Anzahl Retouren. Jetzt möchte ich beide Tabellen joinen und mir für jeden Artikel die Gesamtzahl Sales und die Anzahl Retouren anzeigen lassen.

Bis jetzt habe ich folgendes Skript, was mir jedoch falsche Ergebnisse liefert:

select s."No_", sum(s."Quantity"), sum(r."Quantity")

from "Sales Invoice Line" s
join "Return Receipt Line" r on s."No_" = r."No_"

where r."Posting Date" between '2014-01-09' and '2014-31-10'group by s."No_"

Die Anzahl s."Quantity" - also die Anzahl verkaufter Artikel - passt. Aber die Anzahl r."Quantity" - Anzahl Retouren - passt nicht und ist viel zu hoch.

Jemand eine Idee?

 

[akretschmer]

Hi zusammen,

ich habe eine Sales Tabelle und eine Retour Tabelle. In beiden stehen Artikelnummern und die Anzahl Sales bzw die Anzahl Retouren. Jetzt möchte ich beide Tabellen joinen und mir für jeden Artikel die Gesamtzahl Sales und die Anzahl Retouren anzeigen lassen.

Bis jetzt habe ich folgendes Skript, was mir jedoch falsche Ergebnisse liefert:

select s."No_", sum(s."Quantity"), sum(r."Quantity")

from "Sales Invoice Line" s
join "Return Receipt Line" r on s."No_" = r."No_"

where r."Posting Date" between '2014-01-09' and '2014-31-10'group by s."No_"

Die Anzahl s."Quantity" - also die Anzahl verkaufter Artikel - passt. Aber die Anzahl r."Quantity" - Anzahl Retouren - passt nicht und ist viel zu hoch.

Jemand eine Idee?

Du hast also:

test=*# select * from sales ;
 kunde | artikel
-------+---------
  1 |  1
  1 |  2
  2 |  2
  2 |  3
(4 rows)

Time: 0,148 ms
test=*# select * from retour ;
 kunde | artikel
-------+---------
  1 |  2
  2 |  2
(2 rows)

Artikel 2 ist als echt Scheiße, gell?

test=*# select s.artikel, s.count, coalesce(r.count,0) from (select artikel, count(1) from sales group by artikel) s left join (select artikel, count(1) from retour group by artikel) r on s.artikel=r.artikel ;
 artikel | count | coalesce
---------+-------+----------
  1 |  1 |  0
  3 |  1 |  0
  2 |  2 |  2
(3 rows)

 

[ukulele]

Die Anzahl s."Quantity" - also die Anzahl verkaufter Artikel - passt. Aber die Anzahl r."Quantity" - Anzahl Retouren - passt nicht und ist viel zu hoch.

Ich kann eigentlich keinen Grund erkennen warum das so ist. Dein JOIN irritiert mich aber etwas, soll das ein INNER JOIN sein? Dann muss aber zu jeder Invoice auch eine Retoure existieren, was ich erstmal für nicht sinnvoll halte aber so nicht beurteilen kann.

 

[Distrilec]

Ist "Posting Date" auch wirklich ein Date ? Oder ist das als String gespeichert ?
Wenn es als String gespeichert ist, ist das der Fehler. -> '2014-31-01', '2014-31-02', etc. ist dann auch mit inbehalten...
Wenn man Date's als String speichert, sollte man immer das YYYY-MM-DD Format benutzen um so etwas zu verhindern

 

[akretschmer]

Wenn man Date's als String speichert, sollte man immer

... das sein lassen und DATE nutzen.

 

[Distrilec]

Richtig... Aber ich dachte das sei selbsterklärend
Ob es taktisch klug ist, wurde hier ja aber auch nicht gefragt

 

[ukulele]

Ich weis auch nicht ob es Sinn macht r.PostingDate einzuschränken ohne das InvoiceDatum auch einzuschränken. Und was ist mit Verkäufen, die vor dem Datum oder Zeitraum statt gefunden haben wo aber die Retoure nach in den ausgewählten Zeitraum fällt?

 

[Distrilec]

Anscheinend ist das so aber gewollt... Alle Invoice Lines und die Retoure in einem gewissen Zeitraum.
Zumindest sagte er, dass das Ergebnis der Invoice Lines so passt

 

[ukulele]

Anscheinend ist das so aber gewollt... Alle Invoice Lines und die Retoure in einem gewissen Zeitraum.
Zumindest sagte er, dass das Ergebnis der Invoice Lines so passt

Bei einem INNER JOIN würden nicht alle InvoiceLines ausgegeben sondern nur diejenigen, zu denen es auch eine Retoure in dem Zeitraum gibt. Ob das Sinn macht weiß ich nicht

 

[Distrilec]

Oh... Ja, richtig
@HRGS85 : Vllt. wäre es ne Idee zu erfahren was du eig. mit deinem Select bezwecken willst ?
Kollektive Verwirrung ist nie ein gutes Zeichen.