Hilfe mit SQL Befehlen

[aVenger]

ich lese aus einer tabelle verschiedene dinge aus. darin sind auch ID's von verschiedenen leuten gespeichert wie z.b. Mitarbeiter.
Die Daten zu den Mitarbeitern stehen in einer anderen Tabelle. Wie kann ich nun am einfachsten den Namen des Mitarbeiters anzeigen anstatt der ID?

[Neomi]

SELECT tab2.name FROM tab1 INNER JOIN tab2 WHERE tab1.id = tab2.id

So in etwa geht das, abhängig von den genauen Strukturen deiner Tabellen natürlich.

[T4ch0n4d3l]

zu langsam

[aVenger]

ich habs jetzt mal so gelöst

while ($datensatz = @mysql_fetch_assoc($result))
{

for ($i = 0; $i < mysql_num_rows($resultuser); $i++)
{
$ID = mysql_result($resultuser, $i, 'Id');
if($ID==$datensatz["Von"]){
$vonn=mysql_result($resultuser, $i, 'Nachname');
$vonv=mysql_result($resultuser, $i, 'Vorname');
}
if($ID==$datensatz["Person"]){
$pern=mysql_result($resultuser, $i, 'Nachname');
$perv=mysql_result($resultuser, $i, 'Vorname');
}


}

echo "<TR STYLE=\"font-size:11px\">";
echo "<TD STYLE=\"border-top:1px solid gray\" WIDTH=\"50px\">" .$datensatz["Art"]. "</TD>";
echo "<TD STYLE=\"border-top:1px solid gray\" WIDTH=\"60px\">" .$datensatz["Datum"]. "</TD>";
echo "<TD STYLE=\"border-top:1px solid gray\" WIDTH=\"30px\">" .$vonn ." ". $vonv. "</TD>";
echo "<TD STYLE=\"border-top:1px solid gray\" WIDTH=\"225px\">".$datensatz["Eintrag"]. "</TD>";
usw....

[TheGamer]

ich lese aus einer tabelle verschiedene dinge aus. darin sind auch ID's von verschiedenen leuten gespeichert wie z.b. Mitarbeiter.
Die Daten zu den Mitarbeitern stehen in einer anderen Tabelle. Wie kann ich nun am einfachsten den Namen des Mitarbeiters anzeigen anstatt der ID?

Mach einen LEFT OUTER JOIN

SELECT A.NAME,B.DATEN FROM NAMEN A LEFT OUTER JOIN DATEN B ON A.ID=B.ID

[Gast]

SELECT tab2.name FROM tab1 INNER JOIN tab2 WHERE tab1.id = tab2.id

So in etwa geht das, abhängig von den genauen Strukturen deiner Tabellen natürlich.

Joins sind sind in der Regel nicht gerade performant weil sie korrelieren.
Trotzdem ist deine Lösung natürlich richtig.

select tab2.name
from tab2
where tab2.id in
( select tab1.id
from tab1
)

[ethrandil]

Na das musst du mir erklären. Du hast doch nichts weiter getan, als der datenbank vorzuschreiben wie sie ihren Join zu tun hat.
Das sollte sie intern ohnehin so optimieren. Ich denke nicht, dass deine lösung bei einer aktuellen DB schneller ist.

- eth

[TheGamer]

Joins sind sind in der Regel nicht gerade performant weil sie korrelieren.
Trotzdem ist deine Lösung natürlich richtig.

select tab2.name
from tab2
where tab2.id in
( select tab1.id
from tab1
)


Das einzige was du hier machst ist einen Join mir mehr Aufwand deinerseits zu schreiben.

Ist das gleiche wenn du von Hamburg nach München mit manueller Schaltung faehrst, anstatt mit Automatik. Beim letzteren musst du weniger tun bzw. deine Hände und kommst trotzdem unverändert gleich ans Ziel.

[ethrandil]

Ich hab mir mal die Mühe gemacht, das zu untermauern. Folgendes sagt mit PostgreSQL 8.1:


EXPLAIN SELECT name FROM tab2 A WHERE A.id IN ( SELECT id FROM tab2 );
QUERY PLAN
----------------------------------------------------------------------------------------
Hash IN Join (cost=36.75..74.28 rows=860 width=32)
Hash Cond: ("outer".id = "inner".id)
-> Seq Scan on tab2 a (cost=0.00..18.60 rows=860 width=36)
-> Hash (cost=31.40..31.40 rows=2140 width=4)
-> Seq Scan on tab1 (cost=0.00..31.40 rows=2140 width=4)

EXPLAIN SELECT name FROM tab2 A LEFT OUTER JOIN tab2 B ON A.id = B.id;
QUERY PLAN
------------------------------------------------------------------------------------------
Hash Left Join (cost=36.75..74.28 rows=860 width=32)
Hash Cond: ("outer".id = "inner".id)
-> Seq Scan on tab2 a (cost=0.00..18.60 rows=860 width=36)
-> Hash (cost=31.40..31.40 rows=2140 width=4)
-> Seq Scan on tab1 b (cost=0.00..31.40 rows=2140 width=4)


Das heißt die Querys werden gleich abgearbeitet. Das gilt übrigens auch für left und inner joins in diesem Fall. (Auch für 'SELECT name FROM tab2 A, tab1 B WHERE A.id = B.id'!)

mfg
- eth

[Shink]

Das heißt die Querys werden gleich abgearbeitet. Das gilt übrigens auch für left und inner joins in diesem Fall. (Auch für 'SELECT name FROM tab2 A, tab1 B WHERE A.id = B.id'!)

mfg
- eth
Ja, das muss aber nicht sein und ist DB-abhängig, oder? Das würde bedeuten, JOINs können je nach DB schneller oder langsamer sein. (Wobei ich eher glaube, die sind eher schneller als langsamer)

[Ganon]

Hmm... naja, was ist bei Datenbanken nicht datenbankabhängig? :D

[Shink]

Hmm... naja, was ist bei Datenbanken nicht datenbankabhängig? :D
Das ist ja das tolle daran. Also, schön höhere Programmiersprachen und ORMs verwenden, dann kann man wenigstens die Schuld von sich schieben.

[Gast]

Ich hab mir mal die Mühe gemacht, das zu untermauern. Folgendes sagt mit PostgreSQL 8.1:


EXPLAIN SELECT name FROM tab2 A WHERE A.id IN ( SELECT id FROM tab2 );
QUERY PLAN
----------------------------------------------------------------------------------------
Hash IN Join (cost=36.75..74.28 rows=860 width=32)
Hash Cond: ("outer".id = "inner".id)
-> Seq Scan on tab2 a (cost=0.00..18.60 rows=860 width=36)
-> Hash (cost=31.40..31.40 rows=2140 width=4)
-> Seq Scan on tab1 (cost=0.00..31.40 rows=2140 width=4)

EXPLAIN SELECT name FROM tab2 A LEFT OUTER JOIN tab2 B ON A.id = B.id;
QUERY PLAN
------------------------------------------------------------------------------------------
Hash Left Join (cost=36.75..74.28 rows=860 width=32)
Hash Cond: ("outer".id = "inner".id)
-> Seq Scan on tab2 a (cost=0.00..18.60 rows=860 width=36)
-> Hash (cost=31.40..31.40 rows=2140 width=4)
-> Seq Scan on tab1 b (cost=0.00..31.40 rows=2140 width=4)


Das heißt die Querys werden gleich abgearbeitet. Das gilt übrigens auch für left und inner joins in diesem Fall. (Auch für 'SELECT name FROM tab2 A, tab1 B WHERE A.id = B.id'!)

mfg
- eth

Hi,
ein gutes DBMS macht zur Performance-
Optimierung aus dem Join eine
Unteranfrage, aber wie gesagt das macht nicht jedes.
Ich kann mich nur dunkel an meine Datenbankvorlesungen an der Uni erinnern wo folgende Punkte genannt worden sind:
• besser mit Unteranfrage als mit Join formulieren
• besser mit Mengenoperation als mit Unteranfrage
formulieren
•Eine Unteranfrage wird im
allgemeinen schneller aus-
gewertet.

[ethrandil]

Darf ich fragen, wann du studiert hast? Mir hat mein Prof erzählt ich solle folgendes machen:

SELECT [was man wissen will] FROM tab1, tab2, ..... WHERE [joinbedingungen] AND [weitere bedingungen]

Begründung: Dann muss man sich nicht mit komplizierten Dingen wie unterschiedlichen joins herumschlagen - das macht jedes echte DMBS von selbst.

DBMS grenzte bewusst Mysql und sqlite aus...

Ich könnte mir vorstellen, dass die Datenbanken da in letzter Zeit einfach besser geworden sind.

- eth

[Der_Donnervogel]

Darf ich fragen, wann du studiert hast? Mir hat mein Prof erzählt ich solle folgendes machen:

SELECT [was man wissen will] FROM tab1, tab2, ..... WHERE [joinbedingungen] AND [weitere bedingungen]

.. und mein Prof hat erklärt, daß man gefälligst das JOIN-Schlüsselwort verwenden soll, um diesen Teil sauber von den echten WHERE-Bedingungen zu trennen (Begründung: deutlich bessere Wartbarkeit).

Begründung: Dann muss man sich nicht mit komplizierten Dingen wie unterschiedlichen joins herumschlagen - das macht jedes echte DMBS von selbst.
Das sagt auch mein Prof. Ein DBMS kann so eine Optimierung eigentlich immer mindestens so gut ausführen wie ein Mensch. Im schlechteren Fall ist aber die Lösung vom Programmierer schlechter, da er im Gegensatz zum Optimizer, kein Wissen über die Interna des DBMS hat. Mein Prof. hat dabei einiges an Ahnung in dem Bereich, da er viele Jahre bei Oracle gearbeitet hat und Datenbanken in- und auswendig kennt.