Hi,
ich möchte eine Tabelle A erst mit zwei Bedingungen filtern, um das entstehende Ergebnis dann derart nutzen, um mit einem LEFT JOIN die Tabelle B drauf zu verheiraten.
Irgendwie bekomme ich das nicht auf die Kette.
Danke!
SQL: Hilfe mit join
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
Ja, das habe ich schon in allen Variationen probiert und komme nicht auf den richtigen output.
Also selbst dann nochmal mit python danach ran?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
A besteht aus:
Spalten: straße, hausnummer, plz, ort, X, Y
B besteht aus:
Spalten: Breite, Höhe, straße, hausnummer, plz, ort
Beide sind voll mit Duplikaten.
Für die Identifizierung der Richtigen muss gelten:
TableA.X IS NULL AND TableA.Y='on'
Bekomme die Richtigen mit:
SELECT *
FROM TableA a
WHERE a.X IS NULL AND a.Y='on'
(2000 Reihen)
Möchte abschließend die Höhe und Breite zu den Richtigen wissen.
Hätte jetzt:
SELECT * from TableA a
LEFT JOIN tableB b ON a.straße=b.straße AND a.hausnummer=b.hausnummer AND a.plz=b.plz AND a.ort=b.ort
WHERE a.X is null and a.Y='on'
Gibt mir aber das falsche Ergebnis. 3500 Reihen.
Spalten: straße, hausnummer, plz, ort, X, Y
B besteht aus:
Spalten: Breite, Höhe, straße, hausnummer, plz, ort
Beide sind voll mit Duplikaten.
Für die Identifizierung der Richtigen muss gelten:
TableA.X IS NULL AND TableA.Y='on'
Bekomme die Richtigen mit:
SELECT *
FROM TableA a
WHERE a.X IS NULL AND a.Y='on'
(2000 Reihen)
Möchte abschließend die Höhe und Breite zu den Richtigen wissen.
Hätte jetzt:
SELECT * from TableA a
LEFT JOIN tableB b ON a.straße=b.straße AND a.hausnummer=b.hausnummer AND a.plz=b.plz AND a.ort=b.ort
WHERE a.X is null and a.Y='on'
Gibt mir aber das falsche Ergebnis. 3500 Reihen.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Dann hast du in Tabelle B 1500 doppelte Datensätze, die jeweils über den Join einem Datensatz in Tabelle A zugewiesen werden können.
Das heißt: Dein Zuordnungskriterium der Adresse funktioniert nicht, weil es hier Dubletten in Tabelle B gibt. Die Daten sind also nicht eindeutig.
Ungetestet:
Sollte dir zeigen, dass es da entsprechend doppelte Einträge gibt.
Das heißt: Dein Zuordnungskriterium der Adresse funktioniert nicht, weil es hier Dubletten in Tabelle B gibt. Die Daten sind also nicht eindeutig.
Ungetestet:
Code: Alles auswählen
SELECT straße, hausnummer, plz, ort, count(*) AS anzahl
FROM tabelleB
GROUP BY 1, 2, 3, 4
ORDER BY 5 DESC;
Zuletzt geändert von sparrow am Freitag 12. Juni 2020, 15:04, insgesamt 1-mal geändert.
- __blackjack__
- User
- Beiträge: 13919
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@naheliegend: Das beide Tabellen voll mit Duplikation sind, keine der beiden Tabellen damit einen eindeutigen (und einfachen) Primärschlüssel hat, und beide Tabellen offenbar eine gemeinsame Teilmenge von redundanten Daten enthalten, ist ein ziemlich kaputter DB-Entwurf. Das sollte man vielleicht erst mal in eine Normalform bringen. Sonst braucht man das auch nicht in eine SQL-Datenbank stecken und kann das gleich alles ”zu Fuss” programmieren.
“Java is a DSL to transform big Xml documents into long exception stack traces.”
— Scott Bellware
— Scott Bellware
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
Schmeißt mir einen Fehler:
Jeder GROUP BY-Ausdruck muss mindestens eine Spalte enthalten, die kein äußerer Verweis ist.
Jeder GROUP BY-Ausdruck muss mindestens eine Spalte enthalten, die kein äußerer Verweis ist.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
-
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
Ja, da hast du natürlich Recht.__blackjack__ hat geschrieben: ↑Freitag 12. Juni 2020, 15:02 @naheliegend: Das beide Tabellen voll mit Duplikation sind, keine der beiden Tabellen damit einen eindeutigen (und einfachen) Primärschlüssel hat, und beide Tabellen offenbar eine gemeinsame Teilmenge von redundanten Daten enthalten, ist ein ziemlich kaputter DB-Entwurf. Das sollte man vielleicht erst mal in eine Normalform bringen. Sonst braucht man das auch nicht in eine SQL-Datenbank stecken und kann das gleich alles ”zu Fuss” programmieren.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"