dedlfix: Datenbankabfrage

Beitrag lesen

Tach!

Wir schweifen für den OP zwar jetzt etwas ab, aber das Thema ist interessant :)

Ja, das pasiert hin und wieder. Das ist sozusagen sein Preis für die kostenlose Hilfestellung, dass wir sein Problem zum Anlass nehmen, um uns mit weitergehenden Facetten zu amüsieren. Ich schweife aber auch gern wieder zu ihm hin, wenn er zu seinem Problem weitere konkrete Fragen hat.

Aber was ist, wenn ich zwei Felder aus der Personen Tabelle brauche. Zwei Subqueries? Würde ich ineffizient nennen.

Ja, das sind die Fälle, wo die Vorteile der Subquery schnell schwinden. Bei zwei Feldern mag man sich unter Umständen noch dazu durchringen, aber bei mehr gewinnt doch der Join. Hier ist es ja dann auch so, dass man die Datenmengen absichtlich mischen möchte, dafür sind Joins ja erfunden worden.

Es gibt aber auch genügend Fälle, wo man einfach mal eben nur in die andere Datenmenge schauen möchte, ob da was oder wieviel davon existiert oder auch nicht. Dann muss man nicht Joinen, sich dabei ein kartesischen Produkt einhandeln, das man gar nicht braucht und haben will, um es dann mit Gruppierung oder gar DISTINCT wieder wegzuklopfen. Das sind dann die Situationen, wo der Neuling Hände über dem Kopf zusammenschlagend ins Forum gerannt kommt.

Und was ist, wenn ich die Sätze gar nicht will, wo es die pers_id der Adressen nicht in der Personentabelle nicht gibt? (Ja ich weiß, ist im Beispiel sehr unwahrscheinlich.) Einen nachgelagerten IS NULL Test einbauen?

Wenn ich dein Beispiel richtig interpretiert habe, dann willst du nur wissen, ob was exstiert oder nicht, und das ist ein Fall, der sich hervorragend mit (NOT) EXISTS() ausdrücken lässt.

Joins sind ein Feature von SQL, auf das die Server optimiert sind, und das sollte man dann auch nutzen. Und ich kann durch INNER JOIN oder RIGHT JOIN entscheiden, ob ich Zeilen ohne Match sehen will oder nicht.

Ich bin zwar nicht im Nebenberuf DBMS-Abfragen-Optimierer, aber ich kann mir vorstellen, dass im Index nachschauen einfacher ist, als erst eine gemeinsame Datenmenge zu erzeugen. Das ist jedoch vermutlich das, was der Optimizer umgeht. Warum sollte man das DBMS dann erst damit beauftragen? Es ist semantisch nicht als das ausgedrückt, was man eigentlich will und der Optimizer führt es (gemutmaßt) auch nicht so aus. Also warum dann diesen Weg gehen? Wie gesagt, ich kenne die Arbeitsweise des Optimizers nicht weiter und kann mit dem Gedankengang auch ganz gehörig neben der Realität liegen.

Der andere Einsatz von Subqueries ist die Exists-Klausel, ABER da kann ich keine Daten herausholen. Nur auf Existenz prüfen.

Ja, wenn genau das mein Ziel ist, nehme ich das genau dafür.

Für den OP glaube ich daher, dass das nichts hilft (es sei denn, du nutzt EXISTS um die Zeilen auszufiltern, wo die Subquery in der SELECT Zeile keine Daten liefert. Aber DAS wäre nun sehr mühsam und vor allem schreibst Du die Subquery dann zweimal).

Das "von dennen ein Lieferschein vorhanden ist und z.B nicht eine Mailadresse von web.de." klingt mir doch genau nach einem EXISTS und einem NOT EXISTS. Wobei ich den zweiten Teil nicht so richtig einzuordnen in der Lage bin. Dazu fehlt mir das Wissen um seine Tabellenstruktur(en). Letzeres ist zudem ein Grund, warum ich auch nur in der Lage bin, eine theoretische Antwort zu geben, selbst wenn ich sie als SQL-Statement formuliert hätte.

dedlfix.