Ich bin nicht bereit, mit JOIN zu arbeiten, wenn ich das gleiche Problem mit einer inneren Abfrage leicht lösen kann:
z.B.
SELECT COLUMN1, ( SELECT COLUMN1 FROM TABLE2 WHERE TABLE2.ID = TABLE1.TABLE2ID ) AS COLUMN2 FROM TABLE1;
Meine Frage ist, ist das eine schlechte Programmierpraxis? Ich finde es einfacher zu lesen und zu pflegen als im Gegensatz zu einem Join.
AKTUALISIEREN
Ich möchte hinzufügen, dass es hier ein tolles Feedback gibt, das im Wesentlichen darauf abzielt, wieder mit JOIN zu arbeiten. Ich bin immer weniger damit beschäftigt, TSQL direkt als Ergebnis von ORM-Lösungen zu verwenden (LINQ to SQL, NHibernate, etc.), aber wenn ich es tue, sind es Dinge wie korrelierte Unterabfragen, die einfacher linear zu tippen sind .
Ich bin nicht bereit, mit JOIN zu arbeiten, wenn ich das gleiche Problem mit einer inneren Abfrage leicht lösen kann:
z.B.
%code%
Meine Frage ist, ist das eine schlechte Programmierpraxis? Ich finde es einfacher zu lesen und zu pflegen als im Gegensatz zu einem Join.
AKTUALISIEREN
Ich möchte hinzufügen, dass es hier ein tolles Feedback gibt, das im Wesentlichen darauf abzielt, wieder mit JOIN zu arbeiten. Ich bin immer weniger damit beschäftigt, TSQL direkt als Ergebnis von ORM-Lösungen zu verwenden (LINQ to SQL, NHibernate, etc.), aber wenn ich es tue, sind es Dinge wie korrelierte Unterabfragen, die einfacher linear zu tippen sind .
Wenn Sie mehr als eine Spalte aus der zweiten Tabelle benötigen, benötigen Sie zwei Unterabfragen. Dies würde normalerweise nicht so gut funktionieren wie ein Join.
Ich persönlich finde das unglaublich schwer zu lesen. Es ist nicht die Struktur, die ein SQL-Entwickler erwartet. Wenn Sie JOIN verwenden, behalten Sie alle Tabellenquellen an einer Stelle, anstatt sie in der gesamten Abfrage zu verteilen.
Was passiert, wenn Sie drei oder vier Joins benötigen? All diese Elemente in die SELECT-Klausel zu integrieren, wird haarig.
Dies entspricht nicht JOIN.
Wenn Sie in TABLE2 für jede Zeile in TABLE1 mehrere Zeilen haben, erhalten Sie sie nicht. Für jede Zeile in TABLE1 erhalten Sie eine Zeilenausgabe, sodass Sie aus TABLE2 nicht mehrere erhalten können.
Deshalb würde ich "JOIN" verwenden: um sicherzustellen, dass ich die Daten bekomme, die ich wollte ...
Nach deinem Update: Ich verwende selten Korrelation außer EXISTS ...
Das ist bei IMO keine schlechte Programmierung, aber es ist ein bisschen hässlich. Es kann tatsächlich eine Leistungssteigerung in Situationen sein, in denen die Unterauswahl aus einer sehr großen Tabelle stammt, während Sie eine sehr kleine Ergebnismenge erwarten (Sie müssen Indizes und Plattform berücksichtigen, 2000 mit einem anderen Optimierer und alle ab 2005). Hier ist, wie ich es formatiere, um leichter zu lesen.
%Vor%Bearbeiten: Dies setzt natürlich voraus, dass Ihr Subselect nur einen Wert zurückgibt, andernfalls könnte er Ihnen schlechte Ergebnisse zurückgeben. Siehe Antwort von gbn.
es macht es viel einfacher, andere Arten von Joins zu verwenden (links outer, cross, usw.), weil die Syntax für diejenigen in Unterabfrage-Begriffen weniger als ideal für die Lesbarkeit ist
Die von Ihnen verwendete Abfrage wurde oft als Ersatz für %code% für die Engines verwendet, bei denen diese fehlte (vor allem %code% vor %code% )
Dieser Ansatz hat einige schwerwiegende Nachteile:
Es kann fehlschlagen, wenn %code% nicht %code%
Einige Suchmaschinen können nichts anderes als %code% für diese Abfrage verwenden
Wenn Sie mehr als eine Spalte auswählen müssen, müssen Sie die Unterabfrage mehrmals schreiben
Wenn Ihr Modul %code% unterstützt, verwenden Sie %code% .
In %code% gibt es jedoch Fälle, in denen eine Aggregatfunktion in einer Unterabfrage auf Auswahlebene effizienter sein kann als die in einer %code% mit einer %code% .
Sehen Sie diesen Artikel in meinem Blog für die Beispiele:
Am Ende des Tages besteht das Ziel beim Schreiben von Code über die funktionalen Anforderungen hinaus darin, die Absicht Ihres Codes einem Leser klar zu machen. Wenn Sie ein JOIN verwenden, ist die Absicht offensichtlich. Wenn Sie eine Unterabfrage in der von Ihnen beschriebenen Weise verwenden, stellt sich die Frage, warum Sie es so gemacht haben. Was wollten Sie erreichen, was ein JOIN nicht erreicht hätte? Kurz gesagt, Sie verschwenden die Zeit des Lesers zu versuchen, festzustellen, ob der Autor ein Problem auf geniale Weise gelöst hat oder ob sie den Code nach einer harten Nacht des Trinkens geschrieben haben.
Ein Join ist normalerweise schneller als eine korrelierte Unterabfrage, da es sich auf die Menge der Zeilen und nicht auf jeweils eine Zeile auswirkt. Ich würde diesen Code nie auf meinen Produktionsserver übertragen lassen.
Und ich finde eine Verbindung viel einfacher zu lesen und zu pflegen.
Ein Join ist normalerweise schneller als eine korrelierte Unterabfrage, da es sich auf die Menge der Zeilen und nicht auf jeweils eine Zeile auswirkt. Ich würde diesen Code nie auf meinen Produktionsserver übertragen lassen.
Und ich finde eine Verbindung viel einfacher zu lesen und zu pflegen.
Dies entspricht nicht JOIN.
Wenn Sie in TABLE2 für jede Zeile in TABLE1 mehrere Zeilen haben, erhalten Sie sie nicht. Für jede Zeile in TABLE1 erhalten Sie eine Zeilenausgabe, sodass Sie aus TABLE2 nicht mehrere erhalten können.
Deshalb würde ich "JOIN" verwenden: um sicherzustellen, dass ich die Daten bekomme, die ich wollte ...
Nach deinem Update: Ich verwende selten Korrelation außer EXISTS ...
Die von Ihnen verwendete Abfrage wurde oft als Ersatz für LEFT JOIN für die Engines verwendet, bei denen diese fehlte (vor allem PostgreSQL vor 7.2 )
Dieser Ansatz hat einige schwerwiegende Nachteile:
Es kann fehlschlagen, wenn TABLE2.ID nicht UNIQUE
Einige Suchmaschinen können nichts anderes als NESTED LOOPS für diese Abfrage verwenden
Wenn Sie mehr als eine Spalte auswählen müssen, müssen Sie die Unterabfrage mehrmals schreiben
Wenn Ihr Modul LEFT JOIN unterstützt, verwenden Sie LEFT JOIN .
In MySQL gibt es jedoch Fälle, in denen eine Aggregatfunktion in einer Unterabfrage auf Auswahlebene effizienter sein kann als die in einer LEFT JOIN mit einer GROUP BY .
Sehen Sie diesen Artikel in meinem Blog für die Beispiele:
Das ist bei IMO keine schlechte Programmierung, aber es ist ein bisschen hässlich. Es kann tatsächlich eine Leistungssteigerung in Situationen sein, in denen die Unterauswahl aus einer sehr großen Tabelle stammt, während Sie eine sehr kleine Ergebnismenge erwarten (Sie müssen Indizes und Plattform berücksichtigen, 2000 mit einem anderen Optimierer und alle ab 2005). Hier ist, wie ich es formatiere, um leichter zu lesen.
%Vor%Bearbeiten: Dies setzt natürlich voraus, dass Ihr Subselect nur einen Wert zurückgibt, andernfalls könnte er Ihnen schlechte Ergebnisse zurückgeben. Siehe Antwort von gbn.
Am Ende des Tages besteht das Ziel beim Schreiben von Code über die funktionalen Anforderungen hinaus darin, die Absicht Ihres Codes einem Leser klar zu machen. Wenn Sie ein JOIN verwenden, ist die Absicht offensichtlich. Wenn Sie eine Unterabfrage in der von Ihnen beschriebenen Weise verwenden, stellt sich die Frage, warum Sie es so gemacht haben. Was wollten Sie erreichen, was ein JOIN nicht erreicht hätte? Kurz gesagt, Sie verschwenden die Zeit des Lesers zu versuchen, festzustellen, ob der Autor ein Problem auf geniale Weise gelöst hat oder ob sie den Code nach einer harten Nacht des Trinkens geschrieben haben.
Tags und Links sql-server