“Matrix climbed Aggregate Mountain and delivered a better way to Sum It.”
- Tera-Tom Coffing
Aggregation_Table
Employee_NoSalary
__________________________
423400100000.00
423401100000.00
423402NULL
SELECT AVG(Salary) as "AVG"
‚Count(Salary) as SalCnt
‚Count(*) as RowCnt
FROM Aggregation_Table ;
What would the result set be from the above query? The next slide shows answers!
SELECT AVG(Salary) as "AVG"
‚Count(Salary) as SalCnt
‚Count(*) as RowCnt
FROM Aggregation_Table ;
Here are your answers!
1) Aggregates Ignore Null Values.
2) Aggregates WANT to come back in one row.
3) You CAN’T mix Aggregates with normal columns unless you use a GROUP BY.
The five aggregates are listed above.
How many rows will the above query produce in the result set?
How many rows will the above query produce in the result set? The answer is one.
If you have a normal column (non aggregate) in your query, you must have a corresponding GROUP BY statement.
If you have a normal column (non aggregate) in your query, you must have a corresponding GROUP BY statement.
Group By Dept_No command allow for the Aggregates to be calculated per Dept_No. The data has also been sorted with the ORDER BY statement.
Both queries above produce the same result. The GROUP BY allows you to either name the column or use the number in the SELECT list just like the ORDER BY.
Will Dept_No 300 be calculated? Of course you know it will . . . NOT!
The system eliminates reading any other Dept_No’s other than 200 and 400. This means that only Dept_No’s of 200 and 400 will come off the disk to be calculated.
The HAVING Clause only works on Aggregate Totals. The WHERE filters rows to be excluded from calculation, but the HAVING filters the Aggregate totals after the calculations, thus eliminating certain Aggregate totals.
The HAVING Clause only works on Aggregate Totals, and in the above example, only Count(*) > 2 can return.