Welche dieser Select-Anweisungen ist "besser" und warum?

Das erste ist besser, weil es logisch kohärent ist. Die Scoping-Bedingung ist für den Join nicht relevant. Daher ist ein Cludge ein Teil des Joins und in diesem Fall ein nicht hilfreicher.

Es gibt keinen Unterschied in der relationalen Algebra. Kriterien aus den Wo und inneren Verbindungen sind austauschbar. Ich benutze beide abhängig von der Lesbarkeit und Situation.

In diesem speziellen Fall könnten Sie auch Folgendes verwenden:

Der einzige Unterschied besteht darin, dass keine Zeile in der Rollentabelle vorhanden sein muss (ich nehme jedoch an, dass Sie referenzielle Integrität haben), und es werden nicht mehrere Zeilen zurückgegeben, wenn roleid nicht eindeutig ist (was fast sicher ist) die meisten Szenarien, die ich vorhersehen konnte).

Am besten probieren Sie diese Abfragen aus und führen Sie sie durch den Ausführungsplan von MS SQL aus. Ich habe das gemacht und die Ergebnisse sehen so aus:

Ausführungsplan, der die identische Leistung von Abfragen zeigt http://img223.imageshack.us/img223/6491/querycompare. png

Wie Sie sehen, ist die Leistung die gleiche ( erteilt, die Ausführung auf Ihrer Datenbank kann zu unterschiedlichen Ergebnissen führen. ) Die beste Abfrage ist also diejenige, die folgt der konsistenten Konvention, die Sie zum Schreiben von Abfragen verwenden.

SQL Server sollte diese Abfragen identisch auswerten. Persönlich würde ich das UND verwenden. Ich möchte alle Kriterien für eine verbundene Tabelle im Join selbst behalten, so dass alles zusammen und leicht zu finden ist.

Beide Abfragen sind identisch. Während der Abfrageverarbeitung wendet der SQL-Server den WHERE-Filter unmittelbar nach dem Anwenden des Join-Bedingungsfilters an, sodass Sie mit den gleichen gefilterten Dingen fertig werden.

Ich bevorzuge # 1, ich glaube, dass es die Absicht der Aussage besser ausdrückt. Dass Sie die beiden Tabellen basierend auf der RoleID & amp; role.id und dass Sie basierend auf @Roleid filtern

Sqlserver hat wahrscheinlich eine Entsprechung der Anweisung "explain plan", die Oracle, PostgreSQL und MySQL in der einen oder anderen Form unterstützen. Es kann sehr nützlich sein, Ihnen zu sagen, wie der Abfrageparser und -optimierer Ihre Abfrage behandeln wird.

Ich würde mit dem ersten gehen, aber denken Sie daran, wenn Sie den Code getestet haben, sollten Sie jede Tabelle explizit auswählen, anstatt * * / p> zu wählen     

Da Sie Spalten nicht aus role holen, sollten Sie sie besser nicht in die FROM -Klausel aufnehmen. Benutze dies:

Auf diese Weise sieht das Optimierungsprogramm nur eine Tabelle in der FROM -Klausel und kann schnell die Kardinalität des Resultsets ermitteln (dh die Anzahl der Zeilen im Resultset ist & lt; = die Anzahl der Zeilen in der Tabelle person ).

Wenn Sie zwei Tabellen mit einem JOIN ausgeben, muss das Optimierungsprogramm in der ON -Klausel nachsehen, ob diese Tabellen equi-verbunden sind und ob eindeutige Indizes für die verbundenen Spalten existieren. Wenn das Prädikat in der ON -Klausel kompliziert ist (mehrere ANDs und ORs) oder einfach falsch (manchmal sehr falsch), wählt der Optimierer möglicherweise eine suboptimale Join-Strategie.

Offensichtlich ist dieses spezielle Beispiel sehr durchdacht, weil Sie persons by roleid = @Roleid direkt filtern können (keine Join oder Sub-Query), aber die obigen Überlegungen sind gültig, wenn Sie nach anderen Spalten in role ( @Rolename für Beispiel).

Würde es bei der Verwendung dieser Abfrage zu einer Leistungssteigerung kommen?