SQL: Hilfe mit join

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MariaDB/MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

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!
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Benutzeravatar
sparrow
User
Beiträge: 4501
Registriert: Freitag 17. April 2009, 10:28

Weil man das nicht tut. Dafür ist die Datenbank da. Das ist ihr Job.
Also in der Abfrage mit dem join entsprechend mit where filteren.
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

sparrow hat geschrieben: Freitag 12. Juni 2020, 14:13 (...)
Also in der Abfrage mit dem join entsprechend mit where filteren.
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 (...)"
Benutzeravatar
sparrow
User
Beiträge: 4501
Registriert: Freitag 17. April 2009, 10:28

Dann zeig doch mal, was du machen willst.
naheliegend
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.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Benutzeravatar
sparrow
User
Beiträge: 4501
Registriert: Freitag 17. April 2009, 10:28

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:

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;
Sollte dir zeigen, dass es da entsprechend doppelte Einträge gibt.
Zuletzt geändert von sparrow am Freitag 12. Juni 2020, 15:04, insgesamt 1-mal geändert.
Benutzeravatar
__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
naheliegend
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.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
naheliegend
User
Beiträge: 439
Registriert: Mittwoch 8. August 2018, 16:42

__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.
Ja, da hast du natürlich Recht.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
Antworten