SQL Abfrage von Inhalt einer anderen Tabelle

webdoktor

webdoktor

Angesehenes Mitglied
Hallo zusammen

Ich habe eine kleine Frage zu einer SQL Abfrage und zwar folgendes:
Ich habe zwei Tabellen.


Tabelle1: id | benutzername | alter | geschlecht
Tabelle2: id | id_benutzer | kommentare | nachricht

Nun möchte ich eine SQL-Abfrage machen welche alle Benutzer (id) von der
Tabelle ausliest welche in der Tabelle 2 (id_benutzer) sind.

Hoffe ich habe mein Vorhaben umschreiben können und würde mich riesig
über eure antworten freuen!

Marco
 
SELECT id FROM Tabelle1 WHERE id=(SELECT id_benutzer FROM Tabelle2)

So wuerd ich das machen mit subqueries ,...oder?
 
Oder so:

SELECT Tabelle1.id FROM Tabelle1, Tabelle2 WHERE Tabelle1.id=Tabelle2.id_benutzer;

Gruss
Lenny
 
Die zweite Lösung liefert Zeilen mehrfach - das ist nicht die gewünschte Lösung.

Wenn man so etwas braucht, dann sollte man eigentlich diese 'alte Form' der Tabellenverknüpfung nicht mehr nutzen, sondern stattdessen die Verknüpfung per Join festlegen:

QUOTE From Tabelle1 As A Inner Join Tabelle2 As B
On A.id = B.id_benutzer


Wenn man dann ein 'richtiges Where - Kriterium' hat (Filter nach 'K%' o.ä.), dann sind diese Filter getrennt von der Tabellenverknüpfung.


Von der Performance her habe ich es schon erlebt, daß die erste Lösung sehr viel performanter war als die zweite. Es gab damals ähnliche Probleme mit dem Erstellen von Plänen wie in diesem Thread erwähnt:

Sql-Hardcore: Kalender mit 5 Min. Kompilierung
 
QUOTE (Jürgen Auer @ Mo 16.11.2009, 20:43) 1) Die zweite Lösung liefert Zeilen mehrfach - das ist nicht die gewünschte Lösung.


2) Von der Performance her habe ich es schon erlebt, daß die erste Lösung sehr viel performanter war als die zweite. Es gab damals ähnliche Probleme mit dem Erstellen von Plänen wie in diesem Thread erwähnt:


Zu 1) Falls IDs mehrfach in der Ergebnismenge vorkommen, dann benutze folgende Query:

SELECT DISTINCT tabelle1.id...


Zu 2) Ein berechtigter Hinweis! Aber wenn du nicht viel Datensätze, z.B. in 4- oder Mehrstelligenbereich, hast, dann ist der Perfomanceunterschied verschwindend klein. Kommt halt auf die konkrete Situation drauf an und sicherlich auch welcher DB-Server du benutzest.

Gruss
Lenny
 
Foreign Key anlegen und über Left/Right/Inner Join gehen, ist m.E. der schnellste und beste Weg.
 
Genau so

QUOTE (Lenny @ Di 17.11.2009, 09:01)Zu 1) Falls IDs mehrfach in der Ergebnismenge vorkommen, dann benutze folgende Query:

SELECT DISTINCT tabelle1.id...


sollte man es nicht machen: Zunächst eine unnötig große Verknüpfung produzieren und diese anschließend mit DISTINCT wieder verkleinern.

Wenn dann nämlich (siehe den verlinkten Thread) dem Optimierer genauere Informationen über die zu erwartenden Kardinalitäten fehlen, dann wird erst die Verknüpfung ausgeführt, produziert damit eine möglicherweise riesengroße Tabelle, auf deren Ergebnis wird dann Distinct angewendet.

Bei der Unterabfrage kann diese eigenständig ausgeführt werden (da sie vom Rest unabhängig ist), dann wird implizit ohnehin ein effektives Distinct gebildet (es gibt da verschiedene Möglichkeiten) und die Grundtabelle danach gefiltert.

Der Foreign Key steckt in allen Join-Lösungen ohnehin schon drin.
 
QUOTE (Jürgen Auer @ Di 17.11.2009, 10:26) Der Foreign Key steckt in allen Join-Lösungen ohnehin schon drin.

Gut dann bitte ich dich jetzt mal eine Datenbank Abfrage über 50.000 Datensätze mit einem speziell angelegten Foreign Key zu machen, beim Anlegen der Datenbank direkt angelegt und dann das ganze nochmal ohne einen Foreign Key, quasi wo du die Verknüpfungen blank reinschreibst.

Mal gucken was schneller ist.
 
QUOTE (lerel @ Di 17.11.2009, 10:33)
QUOTE (Jürgen Auer @ Di 17.11.2009, 10:26) Der Foreign Key steckt in allen Join-Lösungen ohnehin schon drin.

Gut dann bitte ich dich jetzt mal eine Datenbank Abfrage über 50.000 Datensätze mit einem speziell angelegten Foreign Key zu machen, beim Anlegen der Datenbank direkt angelegt und dann das ganze nochmal ohne einen Foreign Key, quasi wo du die Verknüpfungen blank reinschreibst.

Mal gucken was schneller ist.

Eine Join-Verknüpfung zwischen zwei Tabellen macht in den meisten Fällen nur dann Sinn, wenn die eine Tabelle Basistabelle zur anderen (Detail-) Tabelle ist.

In so einem Fall betrachte ich einen Fremdschlüssel ohnehin als selbstverständlich, alleine, um die Integrität der Daten sicherzustellen.

Damit stellt sich das Problem nicht. Das setzt natürlich ein Backend voraus, das Fremdschlüssel unterstützt.
 
Hallo zusammen

Vielen Dank für eure Bemühungen und Antworten. Ich habe die passende Abfrage erstellt
und es funktioniert einwandfrei!

Nochmals herzlichen Dank!
Grüsse Marco
 
QUOTE (lerel @ Di 17.11.2009, 10:33) Mal gucken was schneller ist.

Die Performance wird kaum über den Foreign Key selbst bestimmt - sondern eher über den entsprechenden Index. Hier ergeben sich aber gigantische Unterschiede zwischen den verschiedenen Systemen. Bei Oracle z.B. ist eine Relation ohne entsprechenden Index auf dem FK möglich (was in exotischen Fällen sinnvoll sein kann). Klassischer Oracle Anfängerfehler - was bei wachsenden Applikationen eine mieserable Join Performance über die Relationen ergibt.

Bei mySQL dagegen ist für eine Relation immer ein Index erforderlich
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben