SQL Abfrage vergleich

[Rienne]

vor 3 Stunden schrieb Whiz-zarD:

Man müsste sich aber mal den Explain-Plan anschauen, welche Lösung performanter ist. Das weiß ich gar nicht so richtig.

Ist das nicht auch immer eine Frage des DBMS? Denn viele DBMS optimieren ja intern noch die Abfragen.

 

Und die ganze Diskussion hier mit JOIN und WHERE kapier ich auch nicht so ganz. DENN: letzten Endes kann man jedes JOIN auch mit WHERE darstellen. Ob und in wiefern welche Lösung performanter ist, ist auch wieder eine Frage des DBMS.

[Whiz-zarD]

vor 37 Minuten schrieb Rienne:

Ist das nicht auch immer eine Frage des DBMS? Denn viele DBMS optimieren ja intern noch die Abfragen.

Ja, sicherlich, aber wenn man bei einem DBMS den Explain-Plan aufruft, hat man schon ein sehr gutes Indiz dafür, wie die anderen das in etwa machen.

vor 37 Minuten schrieb Rienne:

DENN: letzten Endes kann man jedes JOIN auch mit WHERE darstellen. Ob und in wiefern welche Lösung performanter ist, ist auch wieder eine Frage des DBMS.

ähm, nein ... O_o
Mit JOIN verbindet man zwei Tabellen zu einer Ergebnismenge und mit WHERE filtert man ...
Wie willst du denn ein JOIN mit einer WHERE-Klausel abbilden?

Bearbeitet 22. November 2016 von Whiz-zarD

[Rienne]

 

vor 49 Minuten schrieb Whiz-zarD:

ähm, nein ... O_o
Mit JOIN verbindet man zwei Tabellen zu einer Ergebnismenge und mit WHERE filtert man ...
Wie willst du denn ein JOIN mit einer WHERE-Klausel abbilden?

Ich rede von den hier angesprochenen Inner Joins. 

Ob ich jetzt "...FROM a, b WHERE a.ID=b.ID" oder "FROM a INNER JOIN b ON a.ID=b.ID" liefert mir das selbe Ergebnis,  oder nicht?

Und die Performance unterscheidet sich bei neueren DBMS auch nicht.

Bearbeitet 22. November 2016 von Rienne

[Fauch]

vor 10 Stunden schrieb Whiz-zarD:

Du redest aber an der Aufgabe völlig vorbei. Das Where befindet sich in einem Subselect. Das hat nichts mit einem Join zu tun. Pro Ergebniszeile werden die Subselects aufgerufen und als Filter-Kriterium wird der Wert Art_Id aus der Ergebniszeile genommen.

Falls du es auch nicht so ganz mitbekommen haben solltest: Das obere Statement ist die offizielle Lösung und das untere Statement ist von @Sawfare. In der offiziellen Lösung gibt es also kein Join.

Ich gebe dir recht, das ging etwas an der Aufgabe vorbei.

Ich wollte damit nur unterstreichen, dass 

1. Nur weil einmal WHERE und einmal JOIN da steht, die Antwort nicht unbedingt falsch sein muss. Schließlich lässt sich die Aufgabe genauso mit einem JOIN lösen.

2. Auch eine Lösung, in der einmal ein impliziter und einmal ein expliziter JOIN vorkommt, gleiche Ergebnisse liefern können.

[Fauch]

vor 9 Stunden schrieb Asura:

Where != Join, egal in welcher Situation.

 

Okay, dann erklär uns doch mal den Unterschied zwischen

 

SELECT User.name, ADRESSE.adresse

FROM USER, ADRESSE

WHERE USER.USERID = ADRESSE.USERFID

und

SELECT USER.name, ADRESSE.adresse

FROM USER

JOIN ADRESSE

ON User.USERID = ADRESSE.USERFID

Und bitte ausführlicher als "einmal steht da WHERE, und einmal steht da JOIN".

 

Bearbeitet 22. November 2016 von Fauch

[Whiz-zarD]

Das erste ist ein sog. implizierter Join, der so nicht mehr verwendet werden sollte, da man hier ein kartesisches produkt erzeugt, welches man dann filtert. Das ist sehr langsam und sehr speicherintensiv.

Explizite Joins hingegen arbeiten direkt mit den Indizes (z.B. mit dem hash Join Algorithmus) und sind somit deutlich schneller und verbrauchen auch weniger Speicher.

Ein  optimizer würde daher versuchen implizite joins in explizite umzuwandeln. Ein implizierter Join kann also nur ein cross Join abbilden. Für alle anderen Arten von Joins werden unterschiedliche Algorithmen verwendet. Das Resultat mag vielleicht das selbe sein. Die Ausführung aber eine völlig andere. 

[Fauch]

vor 6 Minuten schrieb Whiz-zarD:

Das erste ist ein sog. implizierter Join, der so nicht mehr verwendet werden sollte, da man hier ein kartesisches produkt erzeugt, welches man dann filtert. Das ist sehr langsam und sehr speicherintensiv.

Explizite Joins hingegen arbeiten direkt mit den Indizes (z.B. mit dem hash Join Algorithmus) und sind somit deutlich schneller und verbrauchen auch weniger Speicher.

Ein  optimizer würde daher versuchen implizite joins in explizite umzuwandeln. Ein implizierter Join kann also nur ein cross Join abbilden. Für alle anderen Arten von Joins werden unterschiedliche Algorithmen verwendet. Das Resultat mag vielleicht das selbe sein. Die Ausführung aber eine völlig andere. 

Vollkommen richtig.

Und was schließen wir daraus: Beides sind JOINS, und nichts anderes habe ich gesagt.

Zudem ist alles was DBMS intern abläuft, der IHK völlig schnuppe und es wird nicht einen Punkt Abzug geben wenn man einen impliziten JOIN verwendet. Performance wird sowieso nicht beachtet, kann man auch nicht, da nie angegeben wird, welches DBMS denn nun verwendet wird.

Bearbeitet 22. November 2016 von Fauch

[Whiz-zarD]

Der Join passiert aber implizit in der FROM-Klausel und nicht in der WHERE-Klausel...

[Chiyoko]

vor 2 Stunden schrieb Whiz-zarD:

Der Join passiert aber implizit in der FROM-Klausel und nicht in der WHERE-Klausel...

Das ist doch jetzt Hahnebüchen.

Die Frage zielte ja direkt auf eine Prüfungssituation in der IHK ab. Und hier sehe ich JOINS und WHERE als gleichwertig an, da das gleiche Ergebnis geliefert wird. Nach Performance oder "Gute Nudel"-Punkten wird hier nicht bewertet.

Natürlich hast du mit deinen Anmerkungen per se Recht, aber ein Azubi (noch dazu kurz vor der Prüfung) verwirrt und verunsichert alle Zusatzinformationen, die (für die IHK-Prüfung) nicht relevant sind. Eventuell ist hier "weniger mehr". Ohne dich jetzt angreifen zu wollen, ahbe ich persönlich das Gefühl, du willst dich mehr als "Spitzen-Entwickler" profilieren, als hier tatsächlich sinnvoll zu helfen. (Nicht böse gemeint!)

Prinzipiell würde ich sogar sagen (in dem hier beschriebenem Fall), dass der JOIN die vollen Punkte einbringt, da viele Prüfer (Achtung: persönliche Einschätzung, keine Fakten!) diese wohl als geläufiger ansehen bzw. ihnen besser bekannt sind.

 

[Whiz-zarD]

vor 33 Minuten schrieb Chiyoko:

Natürlich hast du mit deinen Anmerkungen per se Recht, aber ein Azubi (noch dazu kurz vor der Prüfung) verwirrt und verunsichert alle Zusatzinformationen, die (für die IHK-Prüfung) nicht relevant sind. Eventuell ist hier "weniger mehr". Ohne dich jetzt angreifen zu wollen, ahbe ich persönlich das Gefühl, du willst dich mehr als "Spitzen-Entwickler" profilieren, als hier tatsächlich sinnvoll zu helfen. (Nicht böse gemeint!)

Nein, ich bin hier so ziemlich der einzige, der tatsächlich auf die Fragen vom Threadersteller eingegangen ist ich versuche auch die gefährlichen Aussagen einiger Nutzer zu korrigieren. Ich habe auch nicht mit der Where- und Join-Geschichte angefangen. Eine Where-Klausel ist nun mal kein Join. Ein impliziter Join ist IMMER nur ein Cross Join und nichts anderes. Was man hinterher in der Where-Klausel filtert, ist eine andere Geschichte. Das Ergebnis ist vielleicht das selbe aber semantisch macht es einen gravierenden Unterschied und auch intern passieren unterschiedliche Dinge. Ein Optimizer versucht daher immer einen impliziten Join in einen expliziten Join zu überführen, weil dadurch die Strategie günstiger wird. So etwas sollte man im Hinterkopf haben, um das Statement schon optimal zu schreiben, weil das Parsen, Optimieren und Erstellung des Explain-Plans auch viel Zeit benötigt. Nicht umsonst finden intern weitere Caching-Strategien statt, die die SQL-Statements und deren Explain-Plan cached. Dabei werden dann Konstanten gegen Platzhalter ausgetauscht, damit der selbe Explain-Plan mit unterschiedlichen Konfigurationen ausgeführt werden kann.

vor 48 Minuten schrieb Chiyoko:

Prinzipiell würde ich sogar sagen (in dem hier beschriebenem Fall), dass der JOIN die vollen Punkte einbringt, da viele Prüfer (Achtung: persönliche Einschätzung, keine Fakten!) diese wohl als geläufiger ansehen bzw. ihnen besser bekannt sind.

Das Problem war aber hier gar nicht der Join, sondern die fehlende Gruppierung ...
Wieso man hier überhaupt auf den Join gekommen ist, ist mir weiterhin schleierhaft.

[neinal]

Du hast auf die Frage geantwortet. Ja. Aber geholfen hast du damit nicht.

Mit einem "nein". Ist niemandem geholfen.

 

Aber diskutiert ruhig weiter. Am Ende wird er dann in der Prüfung sitzen und eventuell eine Fragestellung komplett falsch beantworten. Weil die Aufgabenstellung ja "NICHT RELEVANT" ist. Ich bin raus.

[Whiz-zarD]

vor 15 Minuten schrieb neinal:

Du hast auf die Frage geantwortet. Ja. Aber geholfen hast du damit nicht.

Wenn man mal den ganzen Bullshit löschen wurde, der von den anderen geschrieben wurde, würde man erkennen, dass ich der einzige war, der ihm bei seinen Fragen tatsächlich geholfen hat ... 

[Asura]

Man kann auch sachlich bleiben..^^

Bearbeitet 23. November 2016 von Asura

[neinal]

vor 19 Minuten schrieb Whiz-zarD:

Wenn man mal den ganzen Bullshit löschen wurde, der von den anderen geschrieben wurde, würde man erkennen, dass ich der einzige war, der ihm bei seinen Fragen tatsächlich geholfen hat ... 

Ja.

Und wenn mein Kunde eine Anforderung hat, ignoriere ich diese. Und mache einfach das, worauf ich Lust hab. Ob das danach zur Anforderung passt, spielt ja keine Rolle. Richtig ist es ja trotzdem.

[Whiz-zarD]

Die Anforderungen waren doch klar ...
Er hat die offizielle Lösung gleich mitgeliefert. Es ging doch nur darum, um zu schauen, ob seine Lösung das gleiche macht, wie die offizielle Lösung. Wozu man dann noch tausend Mal nach der Aufgabe fragen muss und wieso man mit "Ein Where ist ein Join" kommt, ist mir ein Rätsel, denn das war gar nicht das Problem ... Die Offizielle Lösung war jetzt auch nicht so schwer zu verstehen, sodass man als Anhaltspunkt noch die Aufgabe hätte benötigen müssen. 

Also komm mal wieder auf den Teppich ...

[neinal]

Wenn mich die Aufgabenstellung dazu interessiert, ist das ja wohl meine Sache.

Und für mich ist es nunmal wichtig. Weil sich die Frage stellt, ob der JOIN sinnvoll ist oder nicht! Es geht nicht immer nur um richtig oder falsch. Sondern auch um sinnvoll oder nicht.

Und der einzige der sich hier aufführt, bist du. Nur weil du anderer Meinung bist und einfach nicht akzeptieren kannst, wenn man andere Dinge fragt, als du es tust. Misch dich einfach nicht ein. Wenn für dich die Frage schon seit deiner ersten Antwort erledigt ist, frage ich mich, warum du immer noch deinen Senf dazu gibst. Anstatt es einfach zu lassen.

[Whiz-zarD]

Wenn das für DICH wichtig ist, dann komme aber nicht mit solchen Sprüchen:

Am 22.11.2016 um 10:21 schrieb neinal:

Ohne Aufgabenstellung wird dir auch niemand sagen können, ob du die volle Punktzahl bekommst.

Ob der Join sinnvoll ist, oder nicht lässt sich auch mit der Aufgabenstellung nicht eindeutig sagen. Es kommt dann auf die eigenen Präferenzen an. Entweder man macht hier ein Join und definiert eine Gruppierung, weil im Select Aggregatsfunktionen aufgerufen worden sind oder man erstellt im Select Subselects. Die Join-Variante hat nun das Problem, dass wenn weitere Spalten im Select ausgewiesen werden sollen, müssen diese Spalten auch noch zusätzlich in die Gruppierung eingepflegt werden. Man hat also einen doppelten Pflegeaufwand. Bei den Subselects kann man einfach weitere Spalten hinzufügen.

Darüber kann man sich gerne unterhalten. Alles andere hat hier aber nichts zu suchen.

[JimTheLion]

Ich glaube ein Lösungsansatz mit WITH-Klausel wäre ganz cool  

Ansonsten hätte ich wohl auf die gruppierten Ergebnisse gejoined und geprüft/gehofft, dass da ein Caching Mechanismus greift und die Berechnungen nicht für jeden Datensatz im Ergebnis ausgeführt werden müssen.

 

Um die Schlammschlacht mal mit weiteren Lösungsansätzen zu unterbrechen  (auch wenn die nicht gefragt sind)