Solution to SQL Aggregation exercise

This is the solution to the last SQL exercise from the series covering the students/disciplines field.

The Third one from the series featured a WITH AS and GROUP BY clause, today we are working more on SQL aggregations such as :

  • MIN
  • MAX
  • AVG

Same Context

You should get the 3 tables (student, discipline, score) with data in them.

Today we use Mysql 8.0.22 version instead of Postgresql. If you have any trouble using any SQL server, don’t hesitate to drop us a comment.


Here is what you should obtain as a result without taking care of coefficients and scale :

Aggregation SQL example

And now the query :

round(AVG(score),2) as average, 
FROM student 
INNER JOIN score ON score.student_id = 
GROUP BY student_id
ORDER BY average DESC;

Nothing fancy here, the only particularity is the alias added to the average function on which is computed a round calculation.

The ORDER BY clause then uses the alias.

Adding the  coefficient will alter a bit the result :

round(AVG(score * coefficient),2) as average, 
FROM student 
INNER JOIN score ON score.student_id = 
INNER JOIN discipline ON = score.discipline_id
GROUP BY student_id
ORDER BY average DESC;
Aggregation with coefficient

The coefficient adds some value to some of the disciplines, the average score is a bit altered.

Query Optimization

At first sight we can not do much to optimize the performance of our query as the student id on which we group by is already an index key.

However we are having an ORDER  BY clause here, but it is set on an aggregate function so how could we create an index on that and if possible, is it good practice ?

Index on aggregate function with SQL

When you start thinking about this, you should end up saying :

“What the heck is that ! You wanna build an index on an aggregate function which needs to process on all rows of the table ??”

And you will be right, that’s non sense as we need to browse all result sets from the score table and apply the aggregate average function.

There could be one way to help in case of high process volume using Materialized views (not available in Mysql but workarounds exist) and creating an index out of it. Nevertheless you should consider the real benefit before using it.

Conclusion :

We will keep the query without index modification :).

Stay tuned for the next exercise on SQL and table relationships.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want more information?

Related links will be displayed within articles for you to pick up another good spot to get more details about software development, deployment & monitoring.

Stay tuned by following us on Youtube.

%d bloggers like this: