Wir entwickeln ETL-Jobs, und unser Berater verwendet beim Zusammenfügen von Tabellen "Old Style" SQL.
%Vor%anstelle der inneren Join-Klausel
%Vor%Meine Frage ist, dass auf lange Sicht das Risiko besteht, das alte "where join" zu verwenden? Wie lange wird diese Art von Joins unterstützt und als ANSI-Standard beibehalten? Unsere Plattform ist SQL Server und mein Hauptgrund ist, dass diese "where Joins" in Zukunft nicht mehr unterstützt werden. In diesem Fall müssen wir alle unsere ETL-Jobs mithilfe des Join-Typs "Inner Join" ändern.
Ich bezweifle, dass "wo Joins" jemals nicht unterstützt werden würde. Es ist einfach nicht möglich, sie nicht zu unterstützen, da sie auf kartesischen Produkten und einfacher Filterung basieren. Sie sind eigentlich keine Joins.
Aber es gibt viele Gründe, die neuere Joinsyntax zu verwenden. Unter anderem:
Warum sollten Sie sich über ein mögliches Risiko in der Zukunft keine Sorgen machen, warum sollten Sie sich nicht über das Risiko Sorgen machen, dem Sie jetzt gegenüberstehen?
Zusätzlich zu Marks Punkten:
Es gibt viele Gründe, implizite Joins zu vermeiden. Die Großen sind:
Ich denke nicht, dass sie in absehbarer Zeit entfernt werden, aber es gibt viele andere Gründe, sie nicht mehr zu verwenden.
Beide Syntaxen werden von den neuesten Versionen von ISO SQL (2003, 2008) unterstützt. Die Verwendung von Kommas zum Angeben eines Kreuz-Joins in der FROM-Klausel ist vollkommen Standard-SQL und wird von allen SQL-Produkten unterstützt, die mir begegnet sind. Es scheint sehr unwahrscheinlich, dass es jemals innerhalb von SQL veraltet oder gar nicht mehr unterstützt wird.
Solange sie nicht *** = und = * für ihre Joinsyntax verwenden (was ab SQL Server 2008 R2 veraltet ), kann ich nicht sehen, dass es auf lange Sicht weggeht, aber wie Mark Byers sagt, gibt es viele Gründe, es nicht zu tun.
Meine größte Sorge wäre, dass wenn sie Joins wie diese schreiben, was sonst sie tun, ist das unkonventionell?
Die Leute hatten einige gute Punkte, aber bis jetzt gibt es zwei große, die nicht erwähnt wurden:
Unabhängig davon, ob die Outer-Joins des alten Stils * = und = * korrekte Ergebnisse lieferten, können sie bestimmte Joins auch nicht richtig bezeichnen. Berücksichtigen Sie die folgende Abfrage. Wir möchten allen Kunden zeigen, die keine Bestellung über $ 100 aufgegeben haben:
%Vor%Versuchen Sie es und drücken Sie das auf die alte Art aus ... wenn Sie können. Ohne Verwendung von abgeleiteten Tabellen.
Für mich ist der große Vorteil der Verwendung richtiger Join-Klauseln die Trennung von Standard-Join-Bedingungen (die in fast jeder Abfrage mit diesen beiden Tabellen angewendet werden) von den speziellen Filtern für diese -Abfrage gebe die gewünschten Zeilen zurück:
%Vor%Diese Trennung bedeutet, dass der Entwickler, der sich die Abfrage ansieht, beim Suchen nach den Unterscheidungsmerkmalen dieser Abfrage nicht mit einer Menge Unordnung zu tun haben muss. Wenn er mit den Tabellen vertraut ist, kann er die FROM-Klausel vollständig überspringen und einfach die WHERE-Klausel lesen, um alle Informationen zu erhalten, die er benötigt. Es ist schneller . Und wenn es Ihnen nicht wichtig ist, schneller zu sein, selbst wenn Sie nur Abfragen mit Ihren Augäpfeln scannen, möchte ich nicht mit Ihnen arbeiten.
Nun, für diejenigen, die denken, dass es etwas Besonderes an der Position von allem gibt, wenn Sie die JOIN-Syntax verwenden, liegen Sie falsch. Die folgende Abfrage funktioniert genauso gut wie die obere:
%Vor%Diese Abfrage hat wahrscheinlich sogar den exakt gleichen Ausführungsplan. Überrascht? Sei nicht. Genau wie die alte Syntax ist der Optimierer derjenige, der dafür verantwortlich ist, herauszufinden, wie Sie Ihre Tabellen basierend auf den von Ihnen gegebenen Bedingungen verknüpfen. Es spielt keine Rolle, wo die Bedingungen sind, solange sie sich nicht auf eine Tabelle beziehen, die noch nicht erwähnt wurde.
Was ist der große Unterschied zwischen den beiden Stilen? Wenn Sie der Meinung sind, dass die zweite oben beschriebene Abfrage schwierig zu verstehen ist und eine verrückte Schreibweise wäre, dann denken Sie natürlich, dass der alte Abfrage-Stil lahm ist. Denn, ehrlich gesagt, ist es unorganisiert, alle Bedingungen wahllos an einen alten Ort zu legen. Das Organisationssystem von JOINs macht Sinn. Wenn du an den alten Stil gewöhnt bist und den neuen Stil nicht wirklich magst, ist das wahrscheinlich, weil Veränderung (für uns alle) unangenehm ist. Aber wenn du es einmal für eine Weile benutzt hast, bin ich mir sicher, dass es bei dir wachsen wird. Zumindest, wenn es nicht ist, kann ich nicht verstehen, warum.
Es ist schwierig, über Eleganz oder Hässlichkeit einer bestimmten Syntaxkonstruktion zu streiten. Du siehst es einfach oder nicht. Durch Kommas getrennte Joinsyntax spiegelt das grundlegende Feature der Relationalen Algebra wider, das die normale Form für Select-Project-Join-Abfragen bestätigt. Die einzige Art von Join, die es entzieht (und daher eine dedizierte Syntax gewährleistet), ist der äußere Join. Zufällige Fehler von fehlenden Gleichheits-Prädikaten, die dazu führen, dass Graph-Disjunktionen beitreten, sind nur eine Frage dessen, wie hochentwickelt Ihr Frontend-SQL-Programmiertool ist (zeigt es überhaupt Join-Graphen an?).
Es ist nicht nur Ästhetik. Produktionsdatenbanken haben häufig Spalten wie CREATED_ON oder COMMENTS für viele Tabellen. In diesem Fall ist die NATURAL JOIN-Syntax einfach gefährlich.
Wie Anthony Molinaro (Autor des populären "SQL-Kochbuchs") es treffend ausdrückte: " Der alte Stil ist kurz und süß und perfekt. ANSI hat es dumpfer gemacht, und für Leute, die sich seit einiger Zeit entwickelt haben, ist es völlig unnötig ".
Die implizierte Syntax für den rechten und linken Join * = und = * ist veraltet und liefert aus gutem Grund nicht immer korrekte Ergebnisse. Wenn sie dies benutzt haben, MÜSSEN sie jetzt repariert werden, da sie Sie derzeit für falsche Ergebnisse gefährden. Dies ist keine Option. Die andere Syntax funktioniert weiterhin, sollte aber aus verschiedenen Gründen ebenfalls ersetzt werden. Erstens ist es sehr einfach, zufällige Kreuzverbindungen zu erhalten, die schlechte Ergebnisse liefern können oder die durch Verwendung von distinct behoben werden, was zu Leistungsproblemen führen kann.
Ein weiteres Problem ist die Wartung. Wenn Benutzer später weitere Joins zur Abfrage hinzufügen und damit beginnen, implizite und explizite Joins erneut zu mischen, können Sie falsche Ergebnisse erhalten und nicht einmal wissen. Es ist SEHR SEHR schlecht, diese Art von crappy Code in Ihrer Codebasis zu hinterlassen. Implied Joins sind auch schwieriger zu verstehen und weil sie oft von Entwicklern geschrieben werden, die Joins nicht verstehen, sind sie möglicherweise nicht das, was Sie brauchen. Und wenn es einen Cross-Join in der Abfrage gibt, wie ist der Betreuer zu wissen, ob es sich um einen Bug (und einen zufälligen Cross-Join) oder einen absichtlichen Cross-Join handelte (wir brauchen sie gelegentlich wirklich). Ich würde diesen Code nicht wie geschrieben akzeptieren. Ich würde darauf bestehen, dass der Inkompetente, der es geschrieben hat, es ohne zusätzliche Kosten repariert.
Wenn Sie befürchten, dass sie aus dem Standard oder aus SQL-Produkten entfernt werden, dann machen Sie sich keine Sorgen. Es wird wahrscheinlich nie passieren.
Dieser "alte Stil" von Join ist nur das: nur eine Frage des Stils. Diejenigen, die es bevorzugen, schwören, dass es Situationen gibt, in denen "Old Style" Joins leichter zu verstehen sind. Obwohl ich selbst nicht ganz davon überzeugt bin, ist eines sicher: Die alten Joins werden von Zeit zu Zeit auftreten, und ein Reengineering-Code, der zu Ihrem persönlichen Stil passt, ist nicht immer angemessen. Gewöhnen Sie sich deshalb an den Stil und lernen Sie damit zu arbeiten.
Tags und Links sql sql-server sql-server-2008 join ansi-sql