Can I use where clause instead of AND in given SQL query? If yes, whats the difference in both?

Question

Came across this query online some where, explaining inner join with a condition (incentive>3k).Was just wondering if I can use where clause instead of 'AND' in below SQL, if yes, whats will be the output difference in both?

SELECT FIRST_NAME,
       INCENTIVE_AMOUNT
FROM employee a
     INNER JOIN incentives B ON A.EMPLOYEE_ID = B.EMPLOYEE_REF_ID
                                AND INCENTIVE_AMOUNT > 3000;

Answer 1

yes, you can try this

Select FIRST_NAME,INCENTIVE_AMOUNT from employee
     inner join incentives B on A.EMPLOYEE_ID=B.EMPLOYEE_REF_ID 
where INCENTIVE_AMOUNT >3000

Answer 2

I guess you can use it

Select FIRST_NAME,INCENTIVE_AMOUNT from 
employee inner join incentives B on 
A.EMPLOYEE_ID=B.EMPLOYEE_REF_ID 
where INCENTIVE_AMOUNT >3000

Answer 3

I don't know about Oracle but, at least for INNER JOIN , MySQL treats the WHERE conditions the same as the join conditions. It checks all of them that can be checked as soon as possible while it computes each row to put in the result set.

These two queries produce the same resultset (and afaik MySQL processes them about the same way):

SELECT FIRST_NAME, INCENTIVE_AMOUNT
FROM employee a
  INNER JOIN incentives B 
     ON A.EMPLOYEE_ID = B.EMPLOYEE_REF_ID AND INCENTIVE_AMOUNT > 3000

and

SELECT FIRST_NAME, INCENTIVE_AMOUNT
FROM employee a
  INNER JOIN incentives B 
WHERE A.EMPLOYEE_ID = B.EMPLOYEE_REF_ID AND INCENTIVE_AMOUNT > 3000

There is no difference in the output of INNER JOIN but if you move the join conditions in the WHERE clause of a LEFT/RIGHT JOIN you get a different result set.

The query:

SELECT FIRST_NAME, INCENTIVE_AMOUNT
FROM employee a
  LEFT JOIN incentives B 
     ON A.EMPLOYEE_ID = B.EMPLOYEE_REF_ID AND INCENTIVE_AMOUNT > 3000

includes in the result set all the rows from table employee , matching with a row full of NULL s the rows that do not have a match (on the join condition) in table b .

But this query:

SELECT FIRST_NAME, INCENTIVE_AMOUNT
FROM employee a
  LEFT JOIN incentives B 
WHERE A.EMPLOYEE_ID = B.EMPLOYEE_REF_ID AND INCENTIVE_AMOUNT > 3000

combines all the rows of table a with all rows of table b and then the WHERE clause keeps only the matching rows from the two tables. Its output is identical with the above two INNER JOIN queries.

Answer 4

They come to the same thing.

However, it is generally considered good practice to use join clauses only for specifying joins, and keep filter predicates in the where clause, hence:

select first_name, incentive_amount
from   employee e
       join incentives i
            on  i.employee_ref_id = e.employee_id
where  i.incentive_amount > 3000

(Note that the inner and outer keywords are optional and in my view redundant clutter, so I never use them.)

In the case of outer joins ( left join , or if you absolutely must, left outer join ), the whole idea of separating the filter predicates and placing them in the where clause goes out of the window, because (for example) if there is no incentive row then i.incentive_amount will be null and so any predicate whatsoever will exclude the row. Some say this is why ANSI join syntax is rubbish and the distinction between join and filter predicates is artificial and pointless, while others see it as a quirk of an otherwise helpful syntax.

select first_name, incentive_amount
from   employee e
       left join incentives i
            on  i.employee_ref_id = e.employee_id
            and i.incentive_amount > 3000

You could still follow the convention for inner joins in the same query, eg:

select first_name, incentive_amount
from   employee e
       join departments d
            on d.department_id = e.department_id
       left join incentives i
            on  i.employee_ref_id = e.employee_id
            and i.incentive_amount > 3000
where  d.name = 'Philology'

Just to add, I agree with Jonathan Lewis that a and b are terrible aliases for employee and incentives . (By the way, why not employees or incentive ?) In my version I have used the surely more readable e and i .