This question already has answers here:
Inner join vs Where
(19 answers)
Closed 8 years ago.
Is there any difference between
SELECT *
FROM TABLE_A a
JOIN TABLE_B b
ON a.propertyA = b.propertyA
And the query
SELECT * from TABLE_A a, TABLE_B b where a.propertyA=b.propertyA.
INNER JOIN is ANSI (SQL-92) syntax which you use on the first one. It is generally considered more readable, especially when you join lots of tables.
The WHERE syntax (SQL-89) is more relational model oriented. A result of two tables JOIN'ed is a cartesian product of the tables to which a filter is applied which selects only those rows with joining columns matching.
It's easier to see this with the WHERE syntax.
I'd rather go on the ANSI type join because if you some how omit the ON clause, an error is generated whereas the old type of join if you omit the condition on where clause will not produce an error message and thus it will generate cartesian product.
The two examples are the same. Both perform an INNER JOIN operation (even if it's just JOIN in the 2nd example) which basically returns all rows that contain matching results in relation to the ON clause.
My guess is that the JOIN and INNER JOIN operations are just a bit faster since they're designed for that specific purpose while SELECT statements can be modified around to do much more.
The "join" version has been around about 20 years and is preferred because it clearly identifies predicates used for the join as opposed to those used for filtering results.
It also allow outer joins if used with left join (where you still get table_a's row if there isn't a matching row in table_b).
The "comma" version doesn't allow outer joins (you won't get table_a's row if there isn't a matching row in table_b)
Related
This question already has answers here:
Inner join vs Where
(19 answers)
Closed 2 years ago.
I have 2 tables: Order and Customer. Order has a foreign key from Customer:
I can join them in 2 different ways:
First way
Select *
from [Order]
join Customer
on [Order].Customer_id = Customer.id;
Second way
Select *
from [Order],Customer
where [Order].Customer_id = Customer.id;
The 2 queries return the same result set which leads me to my related questions:
Which query is the better of the two?
Is there a difference between them involving time execution?
Why is it that when I search join examples all of them are using the first way?
I learned the second type of query in college - is it wrong to use?
The difference occurs if you are using LEFT OUTER JOIN or RIGHT OUTER JOIN. filtration location matters here because criteria specified in the ON clause is applied before the JOIN is made. Criteria against an OUTER JOINed table provided in the WHERE clause is applied after the JOIN is made. This can produce very different result sets.
In comparison, it doesn't matter for INNER JOINs if the criteria is provided in the ON or WHERE clauses, the result will be the same.
I never got my head around the "new" SQL join syntax, and therefore use the "old" join system, with the (+). I know it's about time I learned it - however I just find the old syntax a lot more intuitive, especially when working with multiple tables with multiple joins.
However I now have an operation which requires two outer joins on the same table. My code is:
SELECT
C.ID,
R.VALUE,
R.LOG_ID,
LOG.ACTION
FROM
C,
R,
LOG
WHERE
C.DELETED IS NULL
AND R.DELETED IS NULL
-- Two joins below
AND R.C_ID(+) = C.ID
AND R.LOG_ID(+) = LOG.ID
However this results in an error:
ORA-01417 - A table may be outer joined to at most one table.
Searching for this error I find that the solution is to use the new syntax For example this answer on SO:
Outer join between three tables causing Oracle ORA-01417 error
So I am aware that some may consider this question a duplicate as it technically already has an answer. However the "old" syntax posed in that question does not contain exactly the same number of tables and joins as I have here, and try as I might, I'm not sure how I would factor this in to my own code.
Is anyone able to assist? Thanks.
I think you want:
SELECT C.ID, R.VALUE, R.LOG_ID, LOG.ACTION
FROM C LEFT JOIN
R
ON R.C_ID = C.ID LEFT JOIN
LOG
ON R.LOG_ID = LOG.I
WHERE C.DELETED IS NULL AND
R.DELETED IS NULL;
The "new" (it is 25 years old) outer join syntax is actually very easy to follow, particularly for a simple example with just LEFT JOIN.
The idea is you want to keep all rows from one table (perhaps subject to filters in the WHERE clause). That is the first table. Then you use a chain of LEFT JOIN to bring in other tables.
All rows from the first table are in the result set. If there are matching rows in the other tables, then columns from those tables come from matching rows. If there are no matches, then the row from the first table is kept.
This question already has answers here:
What is the difference between using a cross join and putting a comma between the two tables?
(8 answers)
Closed last year.
What is the difference?
SELECT a.name, b.name
FROM a, b;
SELECT a.name, b.name
FROM a
CROSS JOIN b;
If there is no difference then why do both exist?
The first with the comma is an old style from the previous century.
The second with the CROSS JOIN is in newer ANSI JOIN syntax.
And those 2 queries will indeed give the same results.
They both link every record of table "a" against every record of table "b".
So if table "a" has 10 rows, and table "b" has 100 rows.
Then the result would be 10 * 100 = 1000 records.
But why does that first outdated style still exists in some DBMS?
Mostly for backward compatibility reasons, so that some older SQL's don't suddenly break.
Most SQL specialists these days would frown upon someone who still uses that outdated old comma syntax. (although it's often forgiven for an intentional cartesian product)
A CROSS JOIN is a cartesian product JOIN that's lacking the ON clause that defines the relationship between the 2 tables.
In the ANSI JOIN syntax there are also the OUTER joins: LEFT JOIN, RIGHT JOIN, FULL JOIN
And the normal JOIN, aka the INNER JOIN.
But those normally require the ON clause, while a CROSS JOIN doesn't.
And example of a query using different JOIN types.
SELECT *
FROM jars
JOIN apples ON apples.jar_id = jars.id
LEFT JOIN peaches ON peaches.jar_id = jars.id
CROSS JOIN bananas AS bnns
RIGHT JOIN crates ON crates.id = jars.crate_id
FULL JOIN nuts ON nuts.jar_id = jars.id
WHERE jars.name = 'FruityMix'
The nice thing about the JOIN syntax is that the link criteria and the search criteria are separated.
While in the old comma style that difference would be harder to notice. Hence it's easier to forget a link criteria.
SELECT *
FROM crates, jars, apples, peaches, bananas, nuts
WHERE apples.jar_id = jars.id
AND jars.name = 'NuttyFruitBomb'
AND peaches.jar_id = jars.id(+)
AND crates.id(+) = jar.crate_id;
Did you notice that the first query has 1 cartesian product join, but the second has 2? That's why the 2nd is rather nutty.
Both expressions perform a Cartesian product of the two given tables. They are hence equivalent.
Please note that from SQL style point of view, using JOIN has been the preferred syntax for a long time now.
This question already has answers here:
INNER JOIN ON vs WHERE clause
(12 answers)
Closed 8 years ago.
Hello :) I've got a question on MySQL queries.
Which one's faster and why?
Is there any difference at all?
select tab1.something, tab2.smthelse
from tab1 inner join tab2 on tab1.pk=tab2.fk
WHERE tab2.somevalue = 'value'
Or this one:
select tab1.something, tab2.smthelse
from tab1 inner join tab2 on tab1.pk=tab2.fk
AND tab2.somevalue = 'value'
As Simon noted, the difference in performance should be negligible. The main concern would be ensuring your query correctly expresses your intent, and (especially) you get the expected results.
Generally, you want to add filters to the JOIN clause only if the filter is a condition of the join. In most (not all) cases, a filter should be applied to the WHERE clause, as it is a filter of the overall query, not of the join itself.
AFAIK, the only instance where this really affects the outcome of the query is when using an OUTER JOIN.
Consider the following queries:
SELECT *
FROM Customer c
LEFT JOIN Orders o ON c.CustomerId = o.CustomerId
WHERE o.OrderType = "InternetOrder"
vs.
SELECT *
FROM Customer c
LEFT JOIN Orders o ON c.CustomerId = o.CustomerId AND o.OrderType = "InternetOrder"
The first will return one row for each customer order that has an order type of "Internet Order". In effect, your left join has become an inner join because of the filter that was applied to the whole query (i.e. customers who do not have an "InternetOrder" will not be returned at all).
The second will return at least one row for each customer. If the customer has no orders of order type "Internet Order", it will return null values for all order table fields. Otherwise it will return one row for each customer order of type "Internet Order".
If the constraint is based off the joined table (as yours is) then it makes sense to specify the constraint when you join.
This way MySQL is able to reduce the rows from the joined table at the time it joins, as otherwise it will need to be able to select all data that fulfills the basic JOIN criteria prior to applying the WHERE logic.
In reality you'll see little difference in performance until you get to more complex queries or larger datasets, however limiting the data at each JOIN will be more efficient overall if done well especially if there are good indexes on the joined table.
This question already has answers here:
Explicit vs implicit SQL joins
(12 answers)
Condition within JOIN or WHERE
(10 answers)
Closed 9 years ago.
I know, if you want the inner join of two tables, you can write SQL in the following syntax.
select tableA.columnA
from tableA
inner join tableB on tableA.columnB=tableB.columnB
Alternatively, you can write the following.
select tableA.columnA
from tableA,
tableB
where tableA.columnB=tableB.columnB
so, which is better in terms of performance?
There is no difference in terms of performance. The where clause is in fact the same as INNER JOIN when it comes to relational algabra.
Read here for a brief explaination
Make sure you understand how inner joins work though, inner join will return more records than you might expect if one of your tables contain duplicate records. So basically, for each record in table A, it will return all the matching records in table B, and if the next record in table A matches the same records in table B, they will appear again. Read more here.