Entwickler-Ecke :: Thema anzeigen - Probleme bei einem Inner Join über drei Tabellen

Schneehase - Di 31.08.04 13:34
Titel: Probleme bei einem Inner Join über drei Tabellen

Hallo zusammen!!!

Ich habe vier Tabellen mit folgenden Daten:

1. Tabelle
foezuordnung
pronr;foenr;tabnr
1;1;1
1;2;1

2. Tabelle
Projekte
pronr;proname
1;test projekt

3. Tabelle
Foerderer
foenr;foename
1;foerderer1
2;foerderer2

4. Tabelle
Tabellen
tabnr;tabname
1;Tabelle1

Meine dazugehörige SQL lautet:

Quelltext

1:
2:
3:
4:
5:

SELECT foezuordnung.pronr, projekte.proname ,foezuordnung.foenr,foerderer.foename,foezuordnung.tabnr,tabellen.tabname 
FROM foezuordnung
INNER JOIN projekte ON (foezuordnung.pronr=projekte.pronr)
INNER JOIN foerderer ON (foezuordnung.foenr=foerderer.foenr)
INNER JOIN tabellen ON (foezuordnung.tabnr=tabellen.tabnr)

Leider bekomme ich als Ergebnis nur den Datensatz:

1;projekt1;1;foerderer1;1;Tabelle1

zurück.

Wieso fehlt der DS mit dem Förderer 2? Hat jemand einen Tipp für mich!!!

Danke schonmal im voraus!

Gruß
René Albrecht

j-a-n@gmx.de - Di 31.08.04 15:41

mit joins kriege ich das auch nicht hin. probier mal:

Quelltext

1:
2:
3:
4:
5:

SELECT foezuordnung.pronr, projekte.proname, foezuordnung.foenr, foerderer.foename, foezuordnung.tabnr, tabellen.tabname 
FROM foezuordnung, projekte, foerderer, tabellen
WHERE foezuordnung.pronr=projekte.pronr
AND foezuordnung.foenr=foerderer.foenr
AND foezuordnung.tabnr=tabellen.tabnr

Moderiert von UGrohne: Code-Tags hinzugefügt.

nike - Mi 01.09.04 12:09

Hallo!

Das Problem ist, das in der Tabelle Projekte nur eins aufgefuehrt ist (Nr. 1). Durch den Inner Join werden nur solche Spalten verknuepft, bei denen beide Tabellen mit dem ON-Attribut uebereinstimmen. Daher wird das Projekt 2 abgeschnitten.

Vielleicht hilft die ein LEFT JOIN bei dem SQL:

SELECT foezuordnung.pronr, projekte.proname ,foezuordnung.foenr,foerderer.foename,foezuordnung.tabnr,tabellen.tabname

Quelltext

1:
2:
3:
4:

FROM foezuordnung  
LEFT JOIN projekte ON (foezuordnung.pronr=projekte.pronr)  
INNER JOIN foerderer ON (foezuordnung.foenr=foerderer.foenr)  
LEFT JOIN tabellen ON (foezuordnung.tabnr=tabellen.tabnr)

Die Projektezeile wird dann mit NULL-Werten aufgefuellt beim 2. Projekt, da nicht existent. Das gleiche gilt auch fuer die ausdrucksstarke Tabelle 'tabellen'.

Gruss
nike

j-a-n@gmx.de - Mi 01.09.04 12:18

@nike
das ist so schon richtig.
allerdings wird in der zuordnungstabelle gar nicht auf projekt 2 verwiesen und darf daher gar nicht angezeigt werden.
förderer 2 sollte mit projekt 1 und tabelle 1 angezeigt werden.

nike - Mi 01.09.04 14:32

Hi!

Ups - habe wohl etwas schnell gelesen. Habe das ganze unter Access eben nachgebaut und klappt auf Anhieb mit (allerdings Access-spezifischer Notation):

Quelltext

1:
2:
3:
4:

SELECT [foezuordnung].[pronr], [projekte].[proname], [foezuordnung].[foenr], [foerderer].[foename], [foezuordnung].[tabnr], [tabellen].[tabname]
FROM ((foezuordnung INNER JOIN Foerderer ON [foezuordnung].[foenr]=[Foerderer].[foenr])
 INNER JOIN Projekte ON [foezuordnung].[pronr]=[Projekte].[pronr]) 
 INNER JOIN Tabellen ON [foezuordnung].[tabnr]=[Tabellen].[tabnr];

Einziger Unterschied ist die Klammerung.

Welche DB nutzt Du Schneehase?

Gruss
nike

neojones - Do 02.09.04 15:05

j-a-n@gmx.de: Mein altes Steckenpferd, ich sags immer wieder ;-)

Mit Deiner Variante kannst Du Dir bei größeren Datenbanken alles zerschiessen. Hintergrund:

Wenn im FROM mehrere Tabellen stehen wird daraus zunächst das kartesische Produkt abgebildet, also jeder Datensatz jeder Tabelle mit jedem Datensatz jeder anderen Tabelle verknüpft. Daraus entsteht eine gigantische virtuelle Datenmenge die eventuell die Leistung des Servers übersteigt. Bei mySQL könnte dann sogar Datenverlust vorkommen...

Es gibt IMHO vielleicht nur 2 oder 3 Anwendungsbereiche, wo man das kartesische Produkt braucht, aber generell ist davon abzuraten.

@schneehase: die eckigen Klammern weglassen, dann hast ne konforme Notation die laufen sollte.

UGrohne - Fr 03.09.04 08:02

neojones hat folgendes geschrieben:

Mit Deiner Variante kannst Du Dir bei größeren Datenbanken alles zerschiessen.

Bisschen OT, aber trotzdem ein kleiner Hinweis: Das mit dem kartesischen Produkt ist nicht bei jeder Datenbank so. Als Beispiel nehme ich DB2 her, da ist sogar dieses Verfahren schneller als über JOINS. Fragt mich nicht warum, aber die IBM-Datenbank dröselt das vorher so schön auf und optimiert das, dass es so ist. Ich habe es selbst mit über 1,5 Mio Datensätzen ausprobiert und war erstaunt ....

neojones - Fr 03.09.04 10:53

Stimmt, DB2 ist aber von der Grundtechnik im Datenbankkern auch keine richtige relationale Datenbank ;-) Gibt auch noch ein paar Ausnahmen bei Datenbanken, wo das von mir geschriebene nicht (ganz) stimmt. Aber im Regelfall isses leider (oder Gott sei Dank) so ;-)

j-a-n@gmx.de - Mi 04.05.05 11:28

Sorry, dass ich erst jetzt antworte bzw. weiterfrage.

neojones hat folgendes geschrieben:

Wenn im FROM mehrere Tabellen stehen wird daraus zunächst das kartesische Produkt abgebildet, also jeder Datensatz jeder Tabelle mit jedem Datensatz jeder anderen Tabelle verknüpft. Daraus entsteht eine gigantische virtuelle Datenmenge die eventuell die Leistung des Servers übersteigt. Bei mySQL könnte dann sogar Datenverlust vorkommen...

Hmm.. so habe ich es auch mal gelernt, allerdings in der Theorie. Eine Datenbank hat aber vorher einen optimierer, der sich so was anschaut und optimals löst. da du mysql erwähnst, muss ich dir da eindeutig widersprechen. MySQL bietet (wie andere db's auch) den "explain" befehl, welcher erklärt, was mysql wirklich macht. Die gleiche Abfrage, einmal mit wheres und einmal mit joins liefert das gleiche ergebnis!.

Jetzt wäre für mich nur noch interessant, ob paradox das auch macht oder zu d..f dazu ist.

Moderiert von Motzi: Quote-Tags korrigiert.

neojones - Do 05.05.05 20:56

@j-a-n@gmx.de: Der mySQL-Profiler ist derart schlecht (bis V 4.1), dass er i.d.R. große Abhängigkeiten nicht korrekt auflöst.

Von dem her halte ich es immer so: Genau wissen, was man tut und nicht irgendwas tun und die Datenbank selbst optimieren lassen. Man weiss nie was bei rauskommt.

Und als Ergänzung dazu noch: Paradox hat keinen Profiler.

Viele Grüße,

Matthias

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!