SQL Frage

SQL Frage (55 Beiträge, 680 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Habe folgende Frage zu einer SQL Abfrage.

Ich habe ungefähr folgende Struktur: (Anbei dient das nur zur Anschauung)

Namen

ID Name

1  Peter
2  Hannes
3 Klaus

Und eine Tabelle 2 (Notizen)

ID NamenID Text
1    1      Peter ist super

Nun hätte ich gerne folgendes Ergebnis

Peter Peter ist super
Hannes NULL
Klaus NULL

Wenn ich mit Joins arbeite, dann bekomme ich ja nur Daten raus sofern diese Daten miteinander verknüpft sind, also es in dem Beispiel auch wirklich Notizen zu den Namen gibt. Wenn nicht, dann liefert er mir ja als Ergebnis in dem Beispiel nur die erste Datenzeile zurück.

Hat jemand nen Tipp für mich?

LEFT oder RIGHT OUTER JOIN ist dein Freund

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Herzlichen Dank an Raydoo für die Fotos

Danke, habs schon. Das kommt davon wenn man ohne 5 Minuten zu probieren gleich aufgibt

Join oder ganz pervers via Subselect

select a.name, b.txt from newtable a, notizen b where a.id = b.id;

select name, (select txt from notizen where newtable.id = id) from newtable;
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

select a.name, b.txt from newtable a, notizen b where a.id = b.id;

Brr... Theta-Style Joins sind einfach nur schiach.

Wenn schon Join, dann richtig:

SELECT a.name, b.txt
FROM newtable a
LEFT JOIN notizen b ON ( b.id = a.id )

Das hat unser Prof damals nicht gekannt oder wollts nicht unterrichten..

Jedenfalls vermeide ich Joins sowieso wie es nur geht.. Bin ein Fan von Subselects

(was Db2 + Java vor paar Jahren noch nicht war, weil das mochte keine PreparedSatements in SubSelects

)
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Das hat unser Prof damals nicht gekannt oder wollts nicht unterrichten..

Na dann würde ich gleich mal alles in Frage stellen, das man bei ihm gelernt hat. Sowas sind Grundlagen.

Jedenfalls vermeide ich Joins sowieso wie es nur geht.. Bin ein Fan von
Subselects (was Db2 + Java vor paar Jahren noch nicht war, weil das mochte
keine PreparedSatements in SubSelects )

So kann man natürlich auch die Perfomance um den zigfachen Faktor drücken

02.11.2011, 16:27 Uhr - Editiert von hellbringer, alte Version: hier

Na dann würde ich gleich mal alles in Frage stellen, das man bei ihm gelernt
hat. Sowas sind Grundlagen.

Wielange schon? Bzw. scheinbar fand er die "standard Joins" halt nicht böse und somit die andere nicht von Interesse..

Könnte auch sein, dass er sich dachte, wenn bei beiden das gleiche rauskommt, warum 2 Sachen lernen

So kann man natürlich auch die Perfomance um den zigfachen Faktor drücken

Das kann man so nicht stehen lassen..

Ist von DB zu DB verschieden und auch von den Daten.. Warum komplette Tabellen joinen, wenn man eigentlich nur eine Spalte will...

Wenn die Tabelle indexed ist, isses wieder was anderes und der Inner Join wäre sowieso schneller (nur dann brauche ich auch keinen Subselect

).

Und es kommt auf den Query Optimiser auch an...
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Wielange schon?

Seit 1992.

Bzw. scheinbar fand er die "standard Joins" halt nicht böse und somit die
andere nicht von Interesse..

Das ist es ja, Theta-Style ist nicht nach dem ANSI Standard. Deswegen ist es ja so schiach.

Könnte auch sein, dass er sich dachte, wenn bei beiden das gleiche rauskommt,
warum 2 Sachen lernen

Es hätte gereicht nach dem SQL-Standard zu lernen. Den Theta-Mist braucht keine Sau.

Ist von DB zu DB verschieden und auch von den Daten.. Warum komplette Tabellen
joinen, wenn man eigentlich nur eine Spalte will...

Was verstehst du unter "komplette Tabellen joinen"? Ein Sub-Select macht so angewandt auch nichts anderes, nur ineffizienter. Du hast irgendwie eine falsche Vorstellung davon, wie eine Datenbank arbeitet.

Wenn die Tabelle indexed ist, isses wieder was anderes und der Inner Join wäre
sowieso schneller (nur dann brauche ich auch keinen Subselect ).

Ehmm... ich dachte wir reden hier von einem gscheiten Datenbankdesign und nicht von irgendeinem zusammengebastelten Pfusch, wo man zu blöd war Indexe zu setzen.

Und es kommt auf den Query Optimiser auch an...

Ja, das ist klar. Ich sag ja auch nicht, dass Joins immer der beste Weg sind. Aber genauso falsch ist es konsequent auf Sub-Selects zu setzen. Das wäre so, wie mit einem Auto immer im 1. Gang zu fahren, weil man nicht schalten will. Das mag unter bestimmten Bedingungen sinnvoll sein (zB. beim Einparken) aber großteils ist das einfach nur Quatsch.

Seit 1992.

Gut, das hätte der Prof wissen müssen

Das ist es ja, Theta-Style ist nicht nach dem ANSI Standard. Deswegen ist es
ja so schiach.

Wußte ich auch nicht

Was verstehst du unter "komplette Tabellen joinen"? Ein Sub-Select macht so
angewandt auch nichts anderes, nur ineffizienter. Du hast irgendwie eine
falsche Vorstellung davon, wie eine Datenbank arbeitet.

Also wir haben es so gelernt, dass bei nem Join (zumindest bei dem Theta) alles mit allem verknüpft wird und temporär gespeichert wird und nachher mit where nur das selektiert wird, was man braucht..

Ist der left oder right join da viel performanter?

Ehmm... ich dachte wir reden hier von einem gscheiten Datenbankdesign und
nicht von irgendeinem zusammengebastelten Pfusch, wo man zu blöd war Indexe zu
setzen.

Ach, solche Designs werden sooft über Board geworfen...

Ja, das ist klar. Ich sag ja auch nicht, dass Joins immer der beste Weg sind.
Aber genauso falsch ist es konsequent auf Sub-Selects zu setzen. Das wäre so,
wie mit einem Auto immer im 1. Gang zu fahren, weil man nicht schalten will.
Das mag unter bestimmten Bedingungen sinnvoll sein (zB. beim Einparken) aber
großteils ist das einfach nur Quatsch.

Ist mir auch klar, ich bin halt nur ein größerer Fan von Subselects als von Joins, aber ich benutze auch joins (und nicht die Theta

)

Achja, der Theta Join entspricht nicht dem Left Join!

SELECT a.name, b.txt
FROM newtable a
RIGHT JOIN notizen b ON ( b.id = a.id );
= 1: 1 wie Theta

Und der LEFT JOIN = 1:1 wie der Subselect..

Hat man nämlich in newtable eine id, was es in der notizen Tabelle nicht gibt, so wird beim Theta und Right Join der name + txt nicht aufgeführt (weil in der anderen Tabelle nicht gefunden).

Beim Left join oder subselect steht der name und beim txt halt NULL...

Wieder was gelernt und das schon in der Früh

...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Also wir haben es so gelernt, dass bei nem Join (zumindest bei dem Theta)
alles mit allem verknüpft wird und temporär gespeichert wird und nachher mit
where nur das selektiert wird, was man braucht..

Ein Theta-Join ist ja im Prinzip ein CROSS JOIN. Cross Joins sind eigentlich ganz böse, weil sie alles mit allem verknüpfen. Also wenn du pro Tabelle 1000 Datensätze hat, hat das Ergebnis (ohne WHERE-Bedingungen) 1000000 Datensätze.

Ist der left oder right join da viel performanter?

Am performantesten ist der Inner Join. Aber darum geht es nicht. Man entscheidet sich ja zu einem Join anhand der Aufgabenstellung. Was bringt mir ein Inner Join, wenn ich für das Ergebnis ein Left Join brauche? Right Joins sind eher unüblich, weil man bei uns von Links nach Rechts und nicht von Rechts nach Links "denkt".

Die Performance ist auch nicht der Grund, warum ich vom Theta-Style abrate. Das größte Problem ist diese umständliche und unübersichtliche Schreibweise. Je größer die Abfrage ist, umso unübersichtlicher wird das Ganze.

Achja, der Theta Join entspricht nicht dem Left Join!

SELECT a.name, b.txt
FROM newtable a
RIGHT JOIN notizen b ON ( b.id = a.id );
= 1: 1 wie Theta

Was weiß ich. Bei dieser kryptischen Benennung ("newtable", wtf?) wollte ich nicht unnötig meine Gehirnzellen anstrengen.

Tabellen- und Spaltenname sollten immer so gewählt werden, dann man möglichst am ersten Blick versteht, welche Daten sie enthalten. Irgendwelche kryptischen Abkürzungen sind eigentlich nur ein Hindernis.

Also wenn du pro Tabelle 1000 Datensätze hat, hat das Ergebnis (ohne
WHERE-Bedingungen) 1000000 Datensätze.

Eben, das habe ich auch so gelernt...

Und beim Left oder Right Join ist das nicht so?

Das größte Problem ist diese umständliche und unübersichtliche Schreibweise.
Je größer die Abfrage ist, umso unübersichtlicher wird das Ganze.

Gut, das mag Geschmacksache sein..

Zb in meinem Bsp kann ich den Theta Join ganz normal lesen.. Gut wir haben den auch lange genug gelernt...

Was weiß ich. Bei dieser kryptischen Benennung ("newtable", wtf?) wollte ich
nicht unnötig meine Gehirnzellen anstrengen.

Hehe.. War halt ein Quick and Dirty Beispiel mit JerbyDB.. Da waren mir die Namen egal...

Right Joins sind eher unüblich, weil man bei uns von Links nach Rechts und
nicht von Rechts nach Links "denkt".

Naja, kommt auf die Aufgabe drauf an..

Würde ich zuerst von Notizen selektieren und den left join nach newTable machen, dann wäre das Ergebnis auch so wie beim Theta Join oder halt beim Right Join..

Am performantesten ist der Inner Join.

Weiß ja nicht wiefern man Wiki hier vertrauen kann, aber siehe hier:
http://en.wikipedia.org/wiki/Join_(SQL )#Inner_join

Da ist zuerst ein Inner Join und nachher ist ein Theta join was das gleiche Ergebnis liefert... (dann wäre der Theta Join ja gleich schnell, nur die Schreibweise ist halt nicht "schön").

Dort ist der Theta Join eigentlich mit einem Equi-join gleichgesetzt und nicht mit dem Inner Join..

Ich bin jetzt nur noch verwirrt

...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Eben, das habe ich auch so gelernt...

Und beim Left oder Right Join ist das nicht so?

Nein, bei Left und Inner Join wird nur das gejoint, bei dem die ON-Bedingung zutrifft.

Gut, das mag Geschmacksache sein..

Ja, es gibt den falschen und den richtigen Geschmack.

Zb in meinem Bsp kann ich den Theta Join ganz normal lesen..

Ja, weils eine Mini-Fuzzi-Abfrage ist. Abfragen können schon mal über mehrere Bildschirmseiten gehen.

Naja, kommt auf die Aufgabe drauf an..

Würde ich zuerst von Notizen selektieren und den left join nach newTable
machen, dann wäre das Ergebnis auch so wie beim Theta Join oder halt beim
Right Join..

Dann würde man die Reihenfolge der Tabellen umdrehen und einen Left Join machen. Also einen Right Join hab ich in den letzten 5 Jahren ein einziges mal gemacht, und das nur weil ich zu faul war nachträglich zwei Tabellen auszutauschen.

Da ist zuerst ein Inner Join und nachher ist ein Theta join was das gleiche
Ergebnis liefert... (dann wäre der Theta Join ja gleich schnell, nur die
Schreibweise ist halt nicht "schön").

Richtig. Man kann durch Where-Bedingungen aus einem Cross Join ein Inner oder Left Join machen. Aber warum nicht gleich den richtigen Join verwenden, den man auch sofort erkennt und sich die Informationen nicht aus der Where-Bedingung rausklauben muss?

Ich bin jetzt nur noch verwirrt

Mach einfach normale Joins und vergiss den Rest. Hätte euer Professor euch das gleich richtig beigebracht, gäbs diese Verwirrung jetzt nicht.

In 99,9% der Fälle kommst mit LEFT und INNER JOIN aus. Alles andere ist so speziell dass du dich sowieso tiefer mit der Materie auseinander setzen musst.

03.11.2011, 11:38 Uhr - Editiert von hellbringer, alte Version: hier

Nein, bei Left und Inner Join wird nur das gejoint, bei dem die ON-Bedingung
zutrifft.

Na dann isses besser

Ja, es gibt den falschen und den richtigen Geschmack.

Naja, bei Mini-Selects isses egal.. Da isses wirklich nur der Geschmack...

Ja, weils eine Mini-Fuzzi-Abfrage ist. Abfragen können schon mal über mehrere
Bildschirmseiten gehen.

In meinen "großen" Selects die > 400 Zeichen haben, ist ne Mischung aus Left Join und/oder subselects..
Je nachdem was halt gebraucht wird.

Außerdem sind das SQL-Befehle die einmal logisch durchdacht worden sind und dann dynamisch von einem Programm zusammengebaut werden...
Da ist die Lese-Schreibweise sowas von egal.. (wenns halt gut dokumentiert ist)

Richtig. Man kann durch Where-Bedingungen aus einem Cross Join ein Inner oder
Left Join machen. Aber warum nicht gleich den richtigen Join verwenden, den
man auch sofort erkennt und sich die Informationen nicht aus der
Where-Bedingung rausklauben muss?

Wie gesagt, ich kann die Theta joins genauso schnell lesen/erklären, aber wenn der andere performanter ist, dann werde ich auch bei Mini-Selects den nicht mehr verwenden ^^

In 99,9% der Fälle kommst mit LEFT und INNER JOIN aus. Alles andere ist so
speziell dass du dich sowieso tiefer mit der Materie auseinander setzen musst.

Tja, leider hatte ich damals schon oft solche Fälle..

Gut da sind auch bei DBs (Oracle) aufeinmal Indizes verschwunden (oder ein Admin hats gelöscht und dann wars wieder keiner) und man hat sich aufeinmal gewundert, warum der Select solange braucht...
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Gut da sind auch bei DBs (Oracle) aufeinmal Indizes verschwunden (oder ein
Admin hats gelöscht und dann wars wieder keiner) und man hat sich aufeinmal
gewundert, warum der Select solange braucht...

Eigentlich sollte nur der Release-Manager die Datenbanken modifizieren dürfen. Ein Systemadmin hat zwar die Rechte dazu (no na, sonst wärs ja nicht der Systemadmin), aber wird sich von selber da raushalten, weil er weiß, dass es ihm nix angeht. Ist ja auch nicht sein Job sich um die Datenbankstruktur zu kümmern.

Naja, bei Mini-Selects isses egal.. Da isses wirklich nur der Geschmack...

Wenn nur du alleine damit arbeitest, ist es wurst. Aber sobald andere Programmierer dazustoßen, werden sie dir schon auf die Finger hauen, vorausgesetzt es sind auch echte Programmierer und keine Webseitenbastler.

Eigentlich sollte nur der Release-Manager die Datenbanken modifizieren dürfen

Zwischen sollte und Realität ist halt ein Riesen Unterschied..

Unsere Kunden haben es auch geschafft auf Linuxsystem Dateien zu überschreiben, obwohl der Standarduser keine Rechte dazu hat..

Remoteadmins haben uns versprochen sie warens nicht, obwohl es kein andere sein könnte...

vorausgesetzt es sind auch echte Programmierer und keine Webseitenbastler.

Kommt auf die Abteilung drauf an...

Die Webseitenbastler sehen die SQL nicht und für die wirklich großen Selects wird meist auch ein Db-Analyzer verwendet und den sehen sich dann auch paar andere Devs an

...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Zwischen sollte und Realität ist halt ein Riesen Unterschied..

Wieso? Wenn niemand die Berechtigung dazu hat, kann er auch nix machen.

Das Problem war, dass dort soviele Berechtigungen hatten (ich rede vom Kunden selbst), dass es schwer nachvollziehbar war, wer es nun war...

Wie kann ein Standarduser, der Programm X nur ausführen darf, das Programm mit einem PDF ersetzen?!

Das hatten wir nämlich... Da war dann statt blabla.jar aufeinmal ein PDF als blabla.jar, nur das der Office User das eigentlich gar nicht ändern hat können...

Aber es war nie jemand.. Wir durften Fehler suchen und ausbessern gehen (gut, war sowieso bezahlt).
Genauso der DB-Fehler... Wir waren für ein Teil der SW zuständig und mussten DB-Fehler aufdecken..

Die hatten auch Remote-Db-Shutdowns.. Das war sowieso das Beste

Da haben sie Maschinen zum Schulen geklont, aber den Hostnamen in den Shutdownscripten nicht geändert..

Ist halt lustig wenn ein Schulungs-PC eine nicht so kleine Oracle DB mitten im Betrieb runterfährt...

Dafür war das Netz aber nach außen hin gut gesichert

...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Das Problem war, dass dort soviele Berechtigungen hatten (ich rede vom Kunden
selbst), dass es schwer nachvollziehbar war, wer es nun war...

Berechtigungen entziehen. In der Datenbank hat niemand rumzufpuschen. Dafür gibts ja die Applikation, die für die Datenein- und ausgabe verantwortlich ist.

Tjo, sogar ich wußte wie man sich als Admin bei der Db anmeldet..

Und das Unternehmen ist nicht klein

...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Tjo, sogar ich wußte wie man sich als Admin bei der Db anmeldet..Und das
Unternehmen ist nicht klein

Adminpasswort ändern und niemandem geben. Und sich dann über den Aufschrei freuen

03.11.2011, 13:23 Uhr - Editiert von hellbringer, alte Version: hier

Ach wie fies

Nur bin ich nicht mehr dort.. Maybe habens das ja schon geändert, aber ich bin mir auch nicht mehr so sicher wie es genau war...
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Bin ein Fan von Subselects

wie kommst du dazu? die Daten aus einem Subselect muss der SQL-Server aufwändig in einer temporären Tabelle abspeichern und deshalb sollte man Subselects so gut es geht vermeiden!

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Achso und wenn er eine ganze Tabelle joined, speichert der diese nicht dazwischen?
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

nein, da joint er sie einfach nur! (siehe Query Execution Plan)

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Achso und das Ergebnis wird nirgends zwischen gespeichert?!?!

Der erstellt genauso eine temporäre Tabelle wo dann nachher weiterselektiert wird..
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Achso und das Ergebnis wird nirgends zwischen gespeichert?!?!

welches Ergebnis? er joint die beiden Tabellen direkt und macht keine temporäre Tabelle aus dem Ergebnis des Subselects ...

Der erstellt genauso eine temporäre Tabelle wo dann nachher weiterselektiert wird..

nein, macht er nicht ... siehe Query Execution Plan (wie schon vorher erwähnt)

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

er joint die beiden Tabellen direkt und macht keine temporäre Tabelle aus dem
Ergebnis des Subselects ...

Irgendwo müssen die Daten gepuffert sein -> temporäre Tabelle (und wenns nur im RAM ist).
Selbst wenn er "direkt" joined, müsste die DB sich kreuzverweise merken, dass Spalte X von Tabelle A mit Spalte Y aus Tabelle B verknüpft ist..

Die DB erweitert für einen Join ja keine bestehende Tabelle..

siehe Query Execution Plan (wie schon vorher erwähnt)

Das ist die Reihenfolge in welcher eine DB das SQL-Statement abarbeitet oder?

Was soll das jetzt mit einer temporären Tabelle zum tun haben?
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Irgendwo müssen die Daten gepuffert sein

wieso? er vergleicht sie direkt miteinander und gibt sie aus, falls das Ergebnis passt!

Das ist die Reihenfolge in welcher eine DB das SQL-Statement abarbeitet oder?

Was soll das jetzt mit einer temporären Tabelle zum tun haben?

der Query Execution Plan sagt aus, wie die Daten ausgelesen werden! dort sieht man eben, dass bei einem Join keine temporäre Tabelle angelegt wird!

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

wieso? er vergleicht sie direkt miteinander und gibt sie aus, falls das
Ergebnis passt!

Ist halt die Frage, wie das die DB implementiert hat..

Wenn ich die Datensätze nicht sofort abfrage, dann muss er diese ja wo im Speicher halten...

Auf was wollte ich eigentlich hinaus

...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Wenn ich die Datensätze nicht sofort abfrage

mit einem Select fragst du aber die Daten direkt ab und deshalb werden sie nicht zwischengespeichert!

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Wenn ich zB von Java oder SQL einen select mache und der hat > 100.000 Datensätze, wer puffert diese zwischen?

Java oder die DB?
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

dein Szenario hat jetzt nichts mit dem zu tun, worüber wir reden! Fakt ist, dass bei einem Join keine temporäre Daten benötigt werden ... bei einem Subselect hingegen muss der Server für die Ergebnismenge eine temporäre Tabelle anlegen und verarbeitet diese dann weiter! dass dies aufwändiger für den Server ist, kann man mittels des Query Execution Plans auslesen!

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Also laut Wiki: The sub-query is evaluated once for each row processed by the outer query.

Wo soll da wieder ne neue Tabelle angelegt werden?!

Eventuell wenn man von einem Subselect selber selektiert, aber in meinem Bsp wurde ja für jede Reihe der select ausgeführt..
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

mein Query Execution Plan sagt mir, dass eine temporäre Tabelle angelegt wird:

http://666kb.com/i/byco9r8sw6rb861rj.gif

zum Vergleich die selbe Abfrage mittels Join:

http://666kb.com/i/bycodqm4hztzw21yn.gif

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

03.11.2011, 14:41 Uhr - Editiert von -Transformer2K-, alte Version: hier

Gut, dein Bsp hat mit meinem NULL zum tun..

Ok, es haben beide Subselects

Ich habe es aber nicht in der Where Bedingung und mache auch kein IN darauf...

Und du machst auch den bösen Theta Join

...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

welches Szenario meinst du denn dann?

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Na meine Antwort zu dem Thema..

http://forum.geizhals.at/t772802,6614589.html#6614589
...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

gut, das ist dann aber per Definition kein Subselect, sondern einfach nur irgendwas

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

das ist dann aber per Definition kein Subselect, sondern einfach nur irgendwas

Naja, wie heißtn das dann wirklich?

Subsomething wirds ja nicht heißen

...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Subsomething wirds ja nicht heißen

sagt wer?

naja kA, im Volksmund versteht man unter einem Subselect ein Select in der Where-Klausel

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Eigentlich immer noch Subquery oder Subselect halt

http://www.datenbank-sql.de/oracle-subquery.htm

Zumindest nennen die das auch so

...

Apple User sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

ich kenn trotzdem niemanden, der das so macht oder gelernt hätte und deshalb war das für mich nicht so klar

Verkaufe Windows 2008 Std. x64 inkl. 5 CALs, bei Interesse einfach melden!

Ein Sub-Select ist ein Select innerhalb eines äußeren Select-Statements.
In welchem Teil des äußeren Selects das nun steht (im SELECT-Block, im FROM-Block oder im WHERE-Block) ist für den Namen unerheblich.

emefge
Infosauger
_____________________________________________________________________________

Weil die Lichtgeschwindigkeit höher als die Schallgeschwindigkeit ist, hält man viele Leute für helle Köpfe bis man sie reden hört.

"Bekomme ich bei Ihnen so einen ganz kleinen Lötkolben zum CPU reparieren?"

Wieso Realität? Ich hab doch verdammt noch mal was Besseres zu tun!

Theta-Style Joins

Was bitte ist für dich daran Theta-Style?
emefge
Infosauger
_____________________________________________________________________________

Weil die Lichtgeschwindigkeit höher als die Schallgeschwindigkeit ist, hält man viele Leute für helle Köpfe bis man sie reden hört.

"Bekomme ich bei Ihnen so einen ganz kleinen Lötkolben zum CPU reparieren?"

Wieso Realität? Ich hab doch verdammt noch mal was Besseres zu tun!

Was bitte ist für dich daran Theta-Style?

Theta-Style:

SELECT *
FROM table1, table2
WHERE table1.foo = table2.bar

ANSI-Style:

SELECT *
FROM table1
INNER JOIN table2 ON ( table1.foo = table2.bar )

Hm, also soweit ich das damals gelernt habe (vor ~20 Jahren), wurden Join-Bedingungen im Where definiert, das ist SQL-Standard.
Inner Join und (left/right/full) Outer-Join kamen erst später dazu und werden nicht von allen Datenbanken unterstützt.

emefge
Infosauger
_____________________________________________________________________________

Weil die Lichtgeschwindigkeit höher als die Schallgeschwindigkeit ist, hält man viele Leute für helle Köpfe bis man sie reden hört.

"Bekomme ich bei Ihnen so einen ganz kleinen Lötkolben zum CPU reparieren?"

Wieso Realität? Ich hab doch verdammt noch mal was Besseres zu tun!

Hm, also soweit ich das damals gelernt habe (vor ~20 Jahren), wurden
Join-Bedingungen im Where definiert, das ist SQL-Standard.Inner Join und
(left/right/full) Outer-Join kamen erst später dazu und werden nicht von allen
Datenbanken unterstützt.

Tja, heute ist es umgekehrt. ANSI Joins ist der Standard und er alte Rotz wird nach und nach nicht mehr unterstützt.

Außerdem wird jeder vernünftige Programmierer den ANSI Standard einhalten, weil der Theta-Style wirklich sehr unübersichtlich ist und mehr Probleme bringt, als er überhaupt nützt.

07.11.2011, 11:47 Uhr - Editiert von hellbringer, alte Version: hier

er alte Rotz wird nach und nach nicht mehr unterstützt

also dass "Tabelle1.Feld1 = Tabelle2.Feld2" in der WHERE-Klausel mal nicht mehr unterstützt wird kann ich mir beim besten Willen ned vorstellen.
emefge
Infosauger
_____________________________________________________________________________

Weil die Lichtgeschwindigkeit höher als die Schallgeschwindigkeit ist, hält man viele Leute für helle Köpfe bis man sie reden hört.

"Bekomme ich bei Ihnen so einen ganz kleinen Lötkolben zum CPU reparieren?"

Wieso Realität? Ich hab doch verdammt noch mal was Besseres zu tun!

also dass "Tabelle1.Feld1 = Tabelle2.Feld2" in der WHERE-Klausel mal nicht
mehr unterstützt wird kann ich mir beim besten Willen ned vorstellen.

Es geht um das Komma zwischen Tabellennamen.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung