This question already has answers here:
INNER JOIN ON vs WHERE clause
(12 answers)
Closed 8 years ago.
These two SQL syntaxtes produces the same result, which one is better to use and why?
1st:
SELECT c.Id,c.Name,s.Id,s.Name,s.ClassId
FROM dbo.ClassSet c,dbo.StudentSet s WHERE c.Id=s.ClassId
2nd:
SELECT c.Id,c.Name,s.Id,s.Name,s.ClassId
FROM dbo.ClassSet c JOIN dbo.StudentSet s ON c.Id=s.ClassId
The 2:nd one is better.
The way youre joining in the first query in considered outdated. Avoid using , and use JOIN
"In terms of precedence, a JOIN's ON clause happens before the WHERE clause. This allows things like a LEFT JOIN b ON a.id = b.id WHERE b.id IS NULL to check for cases where there is NOT a matching row in b."
"Using , notation is similar to processing the WHERE and ON conditions at the same time"
Found the details about it here, MySQL - SELECT, JOIN
Read more about SQL standards
http://en.wikipedia.org/wiki/SQL-92
SELECT c.Id,c.Name,s.Id,s.Name,s.ClassId FROM dbo.ClassSet c JOIN dbo.StudentSet s ON c.Id=s.ClassId
Without any doubt the above one is better when comparing to your first one.In the precedence table "On" is sitting Second and "Where" is on fourth
But for the simpler query like you don't want to break your head like this, for project level "JOIN" is always recommended
Check this link Is a JOIN faster than a WHERE?
Answer by #MehrdadAfshari
Theoretically, no, it shouldn't be any faster. The query optimizer
should be able to generate an identical execution plan. However, some
DB engines can produce better execution plans for one of them (not
likely to happen for such a simple query but for complex enough ones).
You should test both and see (on your DB engine).
The second because it's more readable. That is all.
Related
This question already has answers here:
SQL JOIN vs IN performance?
(6 answers)
Closed 8 years ago.
I have another programmer who wrote a bunch of delete statements that look like this:
DELETE dbo.Test WHERE TestId IN (SELECT TestId FROM #Tests )
(This one is simple but there are others with sub and sub-sub in statements like this)
I always write those kinds of statements as a join. It seems to me that this is like having an in-line function that will be called over and over.
However, I know the optimizer is capable of some serious magic, and new things are added all the time. I have not researched the difference between Join vs In for a while and I thought I would ask if it is still something that should be a join.
Does it matter if you use "join" or "in"?
Most modern SQL optimizers will figure out a join from a clause like this, but it's not guaranteed, and the more complex the query gets, the less likely the optimizer will choose the proper action.
As a general rule, using IN in this sort of scenario is not a good practice. (personal opinion warning) It's really not meant to be used that way.
A good rule of thumb (again, this is debatable but not wrong) is, for using IN, stick to finite lists. For example:
SELECT DISTINCT * FROM foo WHERE id IN (1, 2, 3, ...);
When going against another table, one of these is preferable:
SELECT DISTINCT f.* FROM foo AS f
INNER JOIN bar as b on b.foo_id = f.id;
SELECT DISTINCT * FROM foo AS f
WHERE EXISTS (SELECT NULL FROM bar AS b WHERE b.foo_id = f.id);
Depending on what you are doing, and the nature of your data, your mileage will vary with these.
Note that in this simple example, the IN, the JOIN, and the EXISTS will very likely produce exactly the same query plan. When you start getting into some serious business logic against multiple tables, however, you may find the query plans significantly diverge.
There are three ways we can look at code. Does it functionally work? Does it provide good code maintenance/read-ability? And does it perform well?
Functionally speaking, there is no difference between writing the IN clause or using the join, if both preform the same operation.
From a maintenance/read-ability aspect, one could argue that in the simple cases the join syntax would be straightforward. However, if the sub-query used within the IN clause was a complex multi-join operation, then that may be more descriptive and easier to debug at a later time (put yourself in the shoes of the person who has to look at the code with limited context.)
Finally, from a performance perspective, this would depend on the number of rows in the tables, indexes available (including their statistics), and how the cost based optimizer handles the query ( which may vary depending on the SQL version) as to which would perform better.
So as with most decisions in the IT field, the real answer is … it depends.
The most effective route will be
Delete t1
From table1 t1
Inner Join table2 t2 on t1.col1=t2.col2
In table2 you can assign the temp table (#Tests) which will be much faster.
This question already has answers here:
Oracle Joins - Comparison between conventional syntax VS ANSI Syntax
(11 answers)
Closed 9 years ago.
I have come across many websites to find the answer about which one is better, ANSI or non- ANSI syntax. What is the difference between these two queries?
select a.name,a.empno,b.loc
from tab a, tab b
where a.deptno=b.deptno(+);
and:
select a.name,a.empno,b.loc
from tab a
left outer join tab b on a.deptno=b.deptno;
The result is same in both the cases. The second query is also longer. Which one is better?
suppose if we have added another table Salgrade in the above query based on what conditions we need to join them?? ..
can any one assume one table and give me explanation
both syntaxes usually work without problems, but if you try to add a where condition you will see that with the second one is much simpler to understand which is the join condition and which is the where clause.
1)
SELECT a.name,
a.empno,
b.loc
FROM tab a,
tab b
WHERE a.deptno = b.deptno(+)
AND a.empno = 190;
2)
SELECT a.name,
a.empno,
b.loc
FROM tab a,
LEFT OUTER JOIN tab b
ON a.deptno = b.deptno
WHERE a.empno = 190;
Also, it's much easier to recognize an outer join and do not forget to include the (+). Overall you can say it's just a question of taste, but the truth is that the second syntax is much more readable and less prone to errors.
The first is a legacy Oracle specific way of writing joins, the second is ANSI SQL-92+ standard and is the preferred one.
Extensively discussed many a times, including one by me.
Use explicit JOINs rather than implicit (regardless whether they are outer joins or not) is that it's much easier to accidently create a cartesian product with the implicit joins.
With explicit JOINs you cannot "by accident" create one. The more tables are involved the higher the risk is that you miss one join condition.
Basically (+) is severely limited compared to ANSI joins. Furthermore it is only available in Oracle whereas the ANSI join syntax is supported by all major DBMS
SQL will not start to perform better after migration to ANSI syntax - it's just different syntax.
Oracle strongly recommends that you use the more flexible FROM clause join syntax shown in the former example. In the past there were some bugs with ANSI syntax but if you go with latest 11.2 or 12.1 that should be fixed already.
Using the JOIN operators ensure your SQL code is ANSI compliant, and thus would allow a front-end application to be more easily ported for other database platforms.
Join conditions have a very low selectivity on each table and a high selectivity on the tuples in the theoretical cross product. Conditions in the where statement usually have a much higher selectivity.
Oracle internally converts ANSI syntax to the (+) syntax, you can see this happening in the execution plan's Predicate Information section.
If you are using 11.2 I advise ANSI join. If you use 12C, there are some new bugs unearthed on OUTER JOINS.
I also remember some bugs in Oracle while using ANSI syntax, before 11.2 where it got fixed in 11.2.
In my opinion, I am not a big fan of ANSI syntax, though Oracle does confirm to the standards of ANSI, it is not totally bug free.
please, read this article about joins.
result of your example is not same, if you have data in B table and not in A table
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Explicit vs implicit SQL joins
Stmt1: SELECT ... FROM ((a JOIN b ON <cond1>) JOIN c ON <cond2>)
Stmt2: SELECT ... FROM a, b, c WHERE <cond1> AND <cond2>
I'm not sure whether the second statement can give a smaller resultset. If there are several rows in B matching to one row in A, do we get all these matches with the second statement?
As a final result, yes.
Regarding the execution: the query optimizer might end up creating the same query execution plan for both queries.
This will be the case if, according to its approximate statistics (approximate equi-depth histograms for instance - which are not all the time up-to-date, by the way), the optimizer will determine that the first join is more selective than the second one and, consequently, it will execute this one first.
Stmt1 allows you to specify the order of the joins and, considering that you know exactly what the tables contain, this might be a better solution.
Semantically the queries are going to be identical. However, trying to rely on the plans to prove this is not a good idea.
It would also be possible to drop in arbitrary <cond1>and <cond2> such that the query is valid in the second form but not legal in the first one.
In that sense the second on is more general, but as long as the first one is good, then the second one is equivalent.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Is there something wrong with joins that don't use the JOIN keyword in SQL or MySQL?
Hi,
i'ave always retrieved data without joins...
but is there a benefit to one method over the other?
select * from a INNER JOIN b on a.a = b.b;
select a.*,b.* from a,b where a.a = b.b;
Thanks!
The first method using the INNER JOIN keyword is:
ANSI SQL standard
much cleaner and more expressive
Therefore, I always cringe when I see the second option used - it just bloats up your WHERE clause, and you can't really see at one glance how the tables are joined (on what fields).
Should you happen to forget one of the JOIN conditions in a long list of WHERE clause expressions, you suddenly get a messy cartesian product..... can't do that with the INNER JOIN keyword (you must express what field(s) to join on).
I'd say the biggest benefit is readability. The version with the explicitly named join types are much easier for me to comprehend.
You are using a different syntax for a JOIN, basically. As a matter of best practices, it is best to use the first syntax (explicit JOIN) because it is clearer what the intention of the query is and makes the code easier to maintain.
These are both joins. they are just two different syntactical representations for joins. The first one, (using the "Join" keyword, is the current ANSI Standard (as of 1992 I think).
In the case of inner joins only, the two differeent representations are functionally identical, but the latter ANSI SQL92 standard syntax is much moire readable, once you get used to it, because each individual join condition is associated with the pair of intermediate resultsets being joined together, In the older representation, the join conditions are all together, along with the overall queries' filter conditions, in the where clause, and it is not as clear which is which. This makes identifying bad join conditions (where for example, an unintended cartesian product will be generated) much more difficult.
But more important, perhaps, is that, when performing an outer Join, in certain scenarios, the older syntax is NOT equivilent, and in fact will generate the WRONG resultset.
You should transition to the newer syntax for all your queries.
You've always retrieved the data with joins. The second query is using old syntax, but in the background it is still join :)
This depends on the RDBMS but in the case of SQL server I understand that the utilizing the former syntax allows for better optimization. This is less of a SQL question and more of a vendor specific question.
You can also use the EXPLAIN (SQL Server: Query Execution Plan) type functions to help you understand if there is a difference. Each query is unique and I imagine that the stored statistics can (and will) alter the behavior.
EDIT 9-3-10: I found this blog entry recently that was very enlightening. http://optimizermagic.blogspot.com/2007/12/outerjoins-in-oracle.html
There are times when one or the other join syntax may in fact perform better. I have also found times when a have noticed a slight performance increase (only noticeable in VLDBs) when choosing the Oracle join syntax over the ANSI one. Probably not enough to get fussy over, but for those serious about mastering the Oracle DB, it may be helpful to review the article.
I am aware of two outer join syntaxes for Oracle:
select a, b
from table1
left outer join table2
on table2.foo = table1.foo
OR
select a, b
from table1, table2
where table2.foo(+) = table1.foo
(assuming I got the syntax of the second sample right.)
Is there a performance difference between these? At first I thought it must just be a style preference on the part of the developer, but then I read something that made me think maybe there would be a reason to use one style instead of the other.
"maybe there would be a reason to use
one style instead of the other. "
There are reasons, but not performance related ones. The ANSI style outer joins, as well as being standard, offer FULL OUTER JOINs and outer joins to multiple tables.
Oracle didn't support ANSI syntax prior to version 9i.
Since that version, these queries do the same and yield the same plan.
Correct pre-9i syntax is this:
SELECT a, b
FROM table1, table2
WHERE table2.foo(+) = table1.foo
There is no performance difference. You can also check the execution plans of both queries to compare.
Theoretically, the second query performs the Cartesian product of the two tables and then selects those meeting the join condition. In practice, though, the database engine will optimize it exactly the same as the first.
I found some additional information in answer to my own question. Looks like the old style is very limiting, as of this doc from 3 years ago.
http://www.freelists.org/post/oracle-l/should-one-use-ANSI-join-syntax-when-writing-an-Oracle-application,2
I think perhaps it would only make sense to use the old style if for some reason the queries might be run on an outdated version of Oracle.
The stuff I see at work is almost all in the old style, but it's probably just because the consultants have been working in Oracle since before 9i and they likely didn't see a reason to go update all the old stuff.
Thanks all!
It's not the same. In the first case you're forcing to join the tables in that order.
In the second case Oracle Planner can choose the best option to execute the query.
In this trivial case the result probably will be the same in all the executions, but if you use that syntax in more complex cases the difference will be shown.