SQL View WHERE oder Group by

[mgmito]

Hallo meine SQL Kenntnisse sind nicht allzu gut. Besonders wenn es um die Syntax geht wird es eng.
Ich baue eine Sicht mit 2 Tabellen
Folgende Felder möchte ich drin haben bzw stehen zur Verfügung:

Tabelle 1
OrderID
Ordernumber
Bestellsumme Brutto
Steuer gesamt

Tabelle 2
OrderID
Taxkey (2000 für 7% und 1002 für 19%)
Taxvalue

Jetzt geht es darum eine View zu haben bei der folgende Spalten vorhanden sind

OrderID
Ordernumber
Bestellsumme
Steuer gesamt
Taxvalue 7 %
Taxvalue 19%

Bis jetzt habe ich:
Select Feldernamen
From Tabelle1 LEFT OUTER JOIN Tabelle2 ON Tabelle1.OrderID=Tabelle2.OrderID

Im Moment bekomme ich 2 Zeilen angezeigt mit jeweils der selben OrderID aber verschiedenen Steuberbeträgen. Ich hätte das gerne in einer Zeile mit beiden Taxvalue.

Meine Vermutung Tabelle2 nochmal zu verwenden und irgendwie mit WHERE und/oder Group by arbeiten.

Könnt ihr mir bitte helfen?

GLG Michael

 

[akretschmer]

Meine Vermutung Tabelle2 nochmal zu verwenden und irgendwie mit WHERE und/oder Group by arbeiten.

Du vermutest falsch.

Könnt ihr mir bitte helfen?

GLG Michael

Falls es nicht schon zu spät ist mit MySQL ;-)

test=*# select * from mg1;
 id | brutto
----+--------
  1 |  100
(1 row)

Time: 0,221 ms
test=*# select * from mg2;
 mg1_id | key  | tax
--------+------+-----
  1 | 2000 |  10
  1 | 1002 |  20
(2 rows)

Time: 0,188 ms
test=*# create view v_mg as select mg1.id, mg1.brutto, case when mg2.key=2000 then tax else 0 end as tax7, case when mg2.key=1002 then tax else 0 end as tax19 from mg1 left join mg2 on mg1.id=mg2.mg1_id;
CREATE VIEW
Time: 28,185 ms
test=*# select * from v_mg ;
 id | brutto | tax7 | tax19
----+--------+------+-------
  1 |  100 |  10 |  0
  1 |  100 |  0 |  20
(2 rows)

In vereinfachter Form (und ohne korrekte Zahlen!) sollte es das sein, was Du suchst.

 

[Hony%]

Meine Vermutung Tabelle2 nochmal zu verwenden und irgendwie mit WHERE und/oder Group by arbeiten.

Du suchst vermutlich diese Lösung:

SELECT A.OrderID, A.Ordernumber, B.Taxvalue AS 'Taxvalue 7 %', C.Taxvalue AS 'Taxvalue 19 %'
FROM mgmito1 AS A
LEFT OUTER JOIN mgmito2 AS B
ON A.OrderID = B.OrderID
AND B.Taxkey = 1002
LEFT OUTER JOIN mgmito2 AS C
ON A.OrderID = C.OrderID
AND C.Taxkey = 2000

Datenbasis:

sqlite> select * from mgmito1;
1|eins
2|zwei
3|drei
sqlite> select * from mgmito2;
1|1002|1,7
1|2000|1,19
2|1002|2,7
3|2000|3,19

Ergebnis:

1|eins|1,7|1,19
2|zwei|2,7|
3|drei||3,19

Gruß
Hony

 

[mgmito]

Danke Hony%, also mein Ansatz war schon richtig. Hat mir blos das
AND C.Taxkey = 2000
AND B.Taxkey = 1002

gefehlt. Ich wollte das in der where Stelle eintragen
Danke für die schnelle Hilfe!

 

[akretschmer]

Danke Hony%, also mein Ansatz war schon richtig. Hat mir blos das
AND C.Taxkey = 2000
AND B.Taxkey = 1002

gefehlt. Ich wollte das in der where Stelle eintragen
Danke für die schnelle Hilfe!

Viele Wege führen nach Rom. Dieser aber über 2 Scans der Tabelle, meiner nur mit einem.

Du solltest aber definitiv Dir 'richtige' JOIN-Syntax aneignen, wie @Hony% es gezeigt hat. Also JOIN mit JOIN-Condition und davon unabhängig WHERE-Condition. Das mag in der Ausführung egal sein - es ist besser lesbar und eindeutiger und vermeidet damit Fehler.

 

[Hony%]

Im Moment bekomme ich 2 Zeilen angezeigt mit jeweils der selben OrderID aber verschiedenen Steuberbeträgen. Ich hätte das gerne in einer Zeile mit beiden Taxvalue.

Viele Wege führen nach Rom. Dieser aber über 2 Scans der Tabelle, meiner nur mit einem.

Du hast zwar nur einen Scan aber trotzdem 2 Ergebnistupel pro OrderID. Genau das sollte ja vermieden werden.

 

[akretschmer]

Du hast zwar nur einen Scan aber trotzdem 2 Ergebnistupel pro OrderID. Genau das sollte ja vermieden werden.

Ähm, ja.

Als Ausrede sage ich jetzt mal, daß man das dann natürlich noch aggregieren kann.

 

[Hony%]

Als Ausrede sage ich jetzt mal, daß man das dann natürlich noch aggregieren kann.

Grundsätzlich hast du da Recht. Wir wissen allerdings nichts über die echte Datenbasis und auch nicht über die Semantik von 0 und NULL. Die Werte als Aggregat auszugeben ist streng genommen nicht datentreu. Kann in der Praxis aber natürlich nebensächlich sein.