This question already has answers here:
INNER JOIN ON vs WHERE clause
(12 answers)
Closed 9 years ago.
I have two select join SQL statements:
select a.id from table_a as a, table_b as b where a.id=b.id;
select a.id from table_a as a inner join table_b as b on a.id=b.id;
Obviously, they are the same in result. But is there any difference between them , such as performance, portability.
One difference is that the first option hides the intent by expressing the join condition in the where clause.
The second option, where the join condition is written out is more clear for the user reading the query. It shows the exact intent of the query.
As far as performance or any other difference, there shouldn't be any. Both queries should return the exact same result and perform the same under most RDBMS.
The inner join syntax was added to SQL sometime in the 1990s. It's possible, but unlikely, that the optimizer can do better with it than with the old syntax that used the where clause for the join condition.
They should both be highly portable as things are now.
The inner join syntax is preferable because it is easier on the reader, as others have already remarked.
Both are standard SQL. Different DB systems may optimize them differently, but because they are so simple, I would be a little surprised if they do. But that is the nature of SQL: it is declarative, which gives the implementation a great deal of leeway in how to execute your query. There is no guarantee that these perform the same, or if they are different, which is faster.
They are exactly the same in SQL server. There is no performance difference.
Related
This question already has answers here:
SQL JOIN - WHERE clause vs. ON clause
(22 answers)
Closed 7 years ago.
Way1:
Select * from tableA inner join tableB
on tableA.aid = tableB.aid
where a.condA = xx
AND a.condB = xx
AND a.condC = xx
Way2:
Select * from tableA inner join tableB
on tableA.aid = tableB.aid
AND a.condA = xx
AND a.condB = xx
AND a.condC = xx
Judging from above syntax, is there any significant differences in terms or performances?
Normally, the DBMS should generate the same execution plan.
I find the former one (the JOIN syntax) more obvious then the latter one since it is clearer what you're doing.
No. No difference.
It doesn't make any difference in case of INNER JOIN, both performance wise and result wise.
In case of OUTER JOIN, the placement of condition makes the difference.
They should generate the same execution plan with the same results, the advantage of using example 1 is the readability. In small queries it's okay to use either but as queries get more complex it's nice to have something readable plus be nice to your peers if they ever read your code. It's like formatting, everyone likes neat code, easy to read.
In terms of the queries being equivalent, the only time it really matters is for outer joins. In those cases whether you put the criteria in the join or the where matters. One is applied before/during the outer join and the other after the join. Thus conditions in the where need to handle nulls as the outer join could result in no actual join. So the two queries for an outer join are not equivalent.
Sometimes in inner joins it will matter if the condition will cause a field to be converted into another type. If that is the case there may be a type conversion issues which prevents it from working properly. In other words if your comparing an integer column to a string column and the string column contains 'TEST', well you're going to have a bad time. Unless you exclude those rows via the join condition.
In terms of performance, you want to put the conditions in the join which will hit the index you want to use. Beyond that they should go in the where clause unless they are needed in the join.
But your example may not be the best. It looks like all checks against specific fields for specific values. If you have conditions that just check a value from one table against a constant or variable these are typically not used as join conditions.
This question already has answers here:
Explicit vs implicit SQL joins
(12 answers)
Closed 8 years ago.
select a.name from student a, student b
where a.id = b.id and a.id = 1;
vs
select a.name from student a
inner join student b
on a.id = b.id and a.id = 1;
Are they actually the same?
They are the same as far as the query engine is concerned.
The first type, commonly called a comma join, is an implicit inner join in most (all?) RDBMSs. The syntax is from ANSI SQL 89 and earlier.
The syntax of the second join, called an explicit inner join, was introduced in ANSI SQL 92. It is considered improved syntax because even with complex queries containing dozens of tables it is easy to see the difference between join conditions and filters in the where clause.
The ANSI 92 syntax also allows the query engine to potentially optimize better. If you use a something in the join condition, then it happens before (or as) the join is done. If the field is indexed, you can get some benefit since the query engine will know to not bother with certain rows in the table, whereas if you put it in the WHERE clause, the query engine will need to join the tables completely and then filter out results. Usually the RDBMS will treat them identically -- probably 999 cases out of 1000 -- but not always.
See also:
Why isn't SQL ANSI-92 standard better adopted over ANSI-89?
Obviously they are not the same syntactically, but they are semantically (they return the same). However, I'd write the second one as:
select a.name from student a
inner join student b on a.id = b.id
where a.id = 1;
The join you're doing is pointless because you're giving the same table different alias and joining on the same field i.e. id.
Your select statement should simply be as follows:
SELECT name FROM stud WHERE id = 1
the latter is per ansi standard and the formeris conventionally supported..they are functionally equivalent..if you use the latter, there is greater chance of your SQL being portable across vendors
We have a Oracle 10g and most of our applications are running Oracle Forms 6i. I found that all of the queries written in views/packages/procedures/functions are JOINING tables at WHERE clause level. Example
SELECT * FROM
TABLE_A A,
TABLE_B B,
TABLE_C C,
TABLE_D D
WHERE
A.ID=B.ID(+)
AND B.NO=C.NO(+)
AND C.STATUS=D.ID
AND C.STATUS NOT LIKE 'PENDING%'
This query applies only to ORACLE since it has the (+) join qualifier which is not acceptable in other SQL platforms. The above query is equivalent to:
SELECT * FROM
TABLE_A A LEFT JOIN TABLE_B B ON A.ID=B.ID
LEFT JOIN TABLE_C C ON B.NO=C.NO
JOIN TABLE_D D ON C.STATUS=D.ID
WHERE
C.STATUS NOT LIKE 'PENDING%'
Non of the queries I have seen is written with join taking place in the FROM clause.
My question can be divided into three parts:
Q: Assuming that I have the same Oracle environment, which query is better in terms of performance, cache, CPU load, etc. The first one (joining at WHERE) or the second (joining at FROM)
Q: Is there any other implementation of SQL that accepts the (+) join qualifier other than oracle? if yes, which?
Q: Maybe having the join written at WHERE clause makes the query more readable but compromises the ability to LEFT/RIGHT join, that's why the (+) was for. Where can I read more about the origin of this (+) and why it was invented specifically to Oracle?
Q1. No difference. You can check it using profiling and compare execution plan.
Q2. As I know, only oracle support it. But it is not recommended to use in latest version of Oracle RDBMS:
Oracle recommends that you use the FROM clause OUTER JOIN syntax
rather than the Oracle join operator. Outer join queries that use the
Oracle join operator (+) are subject to the following rules and
restrictions, which do not apply to the FROM clause OUTER JOIN syntax:
Q3. Oracle "invent" (+) before outer join was specified in SQL ANSI.
There should be no performance difference. Assuming you're on a vaguely recent version of Oracle, Oracle will implicitly convert the SQL 99 syntax to the equivalent Oracle-specific syntax. Of course, there are bugs in all software so it is possible that one or the other will perform differently because of some bug. The more recent the version of Oracle, the less likely you'll see a difference.
The (+) operator (and a variety of other outer join operators in other databases) were created because the SQL standard didn't have a standard way of expressing an outer join until the SQL 99 standard. Prior to then, every vendor created their own extensions. It took Oracle a few years beyond that to support the new syntax. Between the fact that bugs were more common in the initial releases of SQL 99 support (not common but more common than they are now), the fact that products needed to continue to support older database versions that didn't support the new syntax, and people being generally content with the old syntax, there is still plenty of code being written today that uses the old Oracle syntax.
A1:
As far as I know they vary in-terms of syntax not in performance. So there is no difference between joining at 'where' clause and joining at 'from' clause.
A2:
To answer this in better way, 'Joining at FROM' clause is standard across all the platforms. So forget about (+) symbols
A3
I have worked in Oracle for sometimes. People use (+) symbols for left/right join because it's easy to write. Some ppl use join at (FROM) clause because it's more readable and understandable.
Hope these points helps you. Please let me know incase am wrong with anything.
One difference between Oracle syntax and ANSI syntax is:
In Oracle syntax you cannot make a FULL OUTER JOIN, there you have to use ANSI syntax.
Oracle introduced ANSI syntax in Oracle 9i - including several bugs. In the meantime since Oracle 11 or 12 it works quite well, but you may discover some obstacles in Oracle 9/10.
Another advandage of ANSI Join syntax is you cannot forget any join condition.
"SELECT * FROM TABLE_A, TABLE_B" performs implicitly a Cross-Join. "SELECT * FROM TABLE_A JOIN TABLE_B" raise an error, you are forced to provide the join condition. If you want to Cross-Join you have to specify it, i.e. "SELECT * FROM TABLE_A CROSS JOIN TABLE_B"
This question already has answers here:
INNER JOIN ON vs WHERE clause
(12 answers)
Closed 9 years ago.
I have two select join SQL statements:
select a.id from table_a as a, table_b as b where a.id=b.id;
select a.id from table_a as a inner join table_b as b on a.id=b.id;
Obviously, they are the same in result. But is there any difference between them , such as performance, portability.
One difference is that the first option hides the intent by expressing the join condition in the where clause.
The second option, where the join condition is written out is more clear for the user reading the query. It shows the exact intent of the query.
As far as performance or any other difference, there shouldn't be any. Both queries should return the exact same result and perform the same under most RDBMS.
The inner join syntax was added to SQL sometime in the 1990s. It's possible, but unlikely, that the optimizer can do better with it than with the old syntax that used the where clause for the join condition.
They should both be highly portable as things are now.
The inner join syntax is preferable because it is easier on the reader, as others have already remarked.
Both are standard SQL. Different DB systems may optimize them differently, but because they are so simple, I would be a little surprised if they do. But that is the nature of SQL: it is declarative, which gives the implementation a great deal of leeway in how to execute your query. There is no guarantee that these perform the same, or if they are different, which is faster.
They are exactly the same in SQL server. There is no performance difference.
This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
WHERE clause better execute before IN and JOIN or after
INNER JOIN versus WHERE clause — any difference?
What, if any, are the differences between the following?
Select
col1,
col2
from TableA A, TableB B
where A.ID = B.ID
and
Select
col1,
col2
From TableA A
Inner Join TableB B on A.ID = B.ID
They seem to have the same behaviors in SQL,
They will likely be optimized to the same thing by the RDBMS. They both JOIN the tables on the A.ID = B.ID criteria.
However, the JOIN syntax is explicit and considered correct.
The former is ANSI-89 syntax, and the latter is ANSI-92 syntax. The latter should almost always be used due to the fact that it's much clearer when you start to use outer joins when expressed in ANSI-92 syntax.
The first syntax is (as you pointed out) a cross join or Cartesian product of the two tables. In a system with no optimizer (or a poor optimizer) this will produce a combination of every record in the first table combined with every record in the second table, then filter them down to just those matching the WHERE clause.
The output from both statements will be the same, and if the system you are using has a good optimizer than the performance will be the same as well.
Two comments I would offer:
1) I find it better to be explicit about your intent when writing statements. If you intended to perform an INNER JOIN then use the INNER JOIN syntax. Future you 6 months form now will be thankful.
2) The optimizer in SQL Server will perform an INNER JOIN in this situation (at least recent versions, can't guarantee all versions), but how well it guesses that path is going to depend on the version of the SQL Server engine and is not guaranteed to remain the same in the future (I doubt it will change in this situation, but is the cost of a few more characters of typing really that high?)
#ypercube correctly pointed out your question is about two different INNER JOIN syntaxes. You don't have any outer join syntax. As #Matt Whitfield pointed out, the first syntax is ANSI-92 and the second one is ANSI-89 style. I agree with matt entirely that in more complicated queries the ANSI-92 syntax is way way more readable.
Furthermore, depending on your version of SQL Server THE ANSI-89 syntax is DEPRECATED and can give you problems. See SR0010: Avoid using deprecated syntax when you join tables or views In fact, in the next version SQL 2011, or Denali, or whatever we're calling it, the ANSI-89 syntax will not be supported. See: Features Not Supported in the Next Version of SQL Server
(search for the word "join").