In order to facilitate learning and testing, all the examples are built under Oracle's own user Scott.
1. rank ()/ dense_rank () over (partition by... Order by...)
Now customers have such a need to query the information of the highest-paid employees in each department. I believe that students with certain oracle application knowledge can write the following SQL statements:In meeting customer needs, we should habitually think about whether there are other ways. This is for sure, using the rank() over(partition by...) or dense_rank() over(partition by...) grammar in the title of this section. The SQL is as follows:
- select e.ename, e.job, e.sal, e.deptno
- from scott.emp e,
- (select e.deptno, max(e.sal) sal from scott.emp e group by e.deptno) me
- where e.deptno = me.deptno
- and e.sal = me.sal;
- select e.ename, e.job, e.sal, e.deptno
- from (select e.ename,
- e.job,
- e.sal,
- e.deptno,
- rank() over(partition by e.deptno order by e.sal desc) rank
- from scott.emp e) e
- where e.rank = 1;
Why do you get the same result as the above statement? Here is a supplement to the rank()/dense_rank() over(partition by e.deptno order by e.sal desc) grammar.
- select e.ename, e.job, e.sal, e.deptno
- from (select e.ename,
- e.job,
- e.sal,
- e.deptno,
- dense_rank() over(partition by e.deptno order by e.sal desc) rank
- from scott.emp e) e
- where e.rank = 1;
over: On what conditions.
partition by e.deptno: by department number (partition).
order by e.sal desc: Rank from high to low (using rank()/dense_rank(), you have to take order by or it's illegal)
rank()/dense_rank():: Classification
The whole sentence means that on the basis of division by department, employees are graded according to their wages from high to low, and "rank" is expressed by numbers from small to large (the minimum must be 1).
So what's the difference between rank() and dense_rank()?
rank(): Jump sort, if there are two first levels, then there is the third level.
dense_rank(): Continuous sorting, if there are two first levels, then it is still the second level.
Homework: Inquire about the minimum wage employees in the department.
2. min()/max() over(partition by...)
Now that we have inquired about the department's maximum/minimum wage, the customer's demand has returned. We have inquired about the employee's information and calculated the difference between the employee's wage and the department's maximum/minimum wage. This is still relatively simple, and it is revised on the basis of the groupby statement in the first section as follows:
Above we used min() and max(), the former for the minimum and the latter for the maximum. What would happen if these two methods were used in conjunction with over(partition by...)? Let's look at the following SQL statements:
- select e.ename,
- e.job,
- e.sal,
- e.deptno,
- e.sal - me.min_sal diff_min_sal,
- me.max_sal - e.sal diff_max_sal
- from scott.emp e,
- (select e.deptno, min(e.sal) min_sal, max(e.sal) max_sal
- from scott.emp e
- group by e.deptno) me
- where e.deptno = me.deptno
- order by e.deptno, e.sal;
The query results of these two statements are the same. You can see that min() and max() actually seek the minimum and maximum, but only on the basis of partition by partition.
- select e.ename,
- e.job,
- e.sal,
- e.deptno,
- nvl(e.sal - min(e.sal) over(partition by e.deptno), 0) diff_min_sal,
- nvl(max(e.sal) over(partition by e.deptno) - e.sal, 0) diff_max_sal
- from scott.emp e;
Homework: What would happen if order by was added to this example?
3. lead()/lag() over(partition by... order by...)
Chinese people like to compare, have good face and are famous all over the world. Customers are even better at this point, but they are not addicted after comparing with the maximum/minimum wage. This time, they put forward a more abnormal demand, calculating the difference between personal wage and one higher/one lower wage than themselves. This requirement really bothers me. I don't know how to implement it in the group by statement. However.... Now that we have over partition by..., everything seems so simple. As follows:
After reading the above sentences, do you also feel a false alarm (a sudden freezing of chickens after a cold sweat, which is easy to catch a cold)? Let's talk about the two new methods used above.
- select e.ename,
- e.job,
- e.sal,
- e.deptno,
- lead(e.sal, 1, 0) over(partition by e.deptno order by e.sal) lead_sal,
- lag(e.sal, 1, 0) over(partition by e.deptno order by e.sal) lag_sal,
- nvl(lead(e.sal) over(partition by e.deptno order by e.sal) - e.sal,
- 0) diff_lead_sal,
- nvl(e.sal - lag(e.sal) over(partition by e.deptno order by e.sal), 0) diff_lag_sal
- from scott.emp e;
Lead (column name, n,m): The default value of column name > in line n after the current record is m if there is no column name; if there is no parameter n,m, the default value is null if there is no column name > in the first row after the current record.
Lag (column name, n,m): The default value of < column name > in line n before the current record is m if there is no record; if there is no parameter n,m, the default value is null if there is no record < column name > in the first row before the current record.
Here are some common methods used in this grammar.
- select e.ename,
- e.job,
- e.sal,
- e.deptno,
- first_value(e.sal) over(partition by e.deptno) first_sal,
- last_value(e.sal) over(partition by e.deptno) last_sal,
- sum(e.sal) over(partition by e.deptno) sum_sal,
- avg(e.sal) over(partition by e.deptno) avg_sal,
- count(e.sal) over(partition by e.deptno) count_num,
- row_number() over(partition by e.deptno order by e.sal) row_num
- from scott.emp e;
Important Note: After reading this article, you may have a misunderstanding that OVER (PARTITION BY.) is better than GROUP BY, but it is not so. The former can not replace the latter, and the former is not as efficient as the latter, but the former provides more functions, so we hope that you can choose according to the needs in use.