Question

In this book I’m currently reading while following a course on databases, the following example of an illegal query using an aggregate operator is given:

Find the name and age of the oldest sailor.

Consider the following attempt to answer this query:

SELECT S.sname, MAX(S.age)
FROM Sailors S

The intent is for this query to return not only the maximum age but
also the name of the sailors having that age. However, this query is
illegal in SQL–if the SELECT clause uses an aggregate operation, then
it must use only aggregate operations unless the query contains a GROUP BY clause!

Some time later while doing an exercise using MySQL, I faced a similar problem, and made a mistake similar to the one mentioned. However, MySQL didn’t complain and just spit out some tables which later turned out not to be what I needed.

Is the query above really illegal in SQL, but legal in MySQL, and if so, why is that?
In what situation would one need to make such a query?

Further elaboration of the question:

The question isn’t about whether or not all attributes mentioned in a SELECT should also be mentioned in a GROUP BY.
It’s about why the above query, using atributes together with aggregate operations on attributes, without any GROUP BY is legal in MySQL.

Let’s say the Sailors table looked like this:

+----------+------+
| sname    | age  |
+----------+------+
| John Doe |   30 |
| Jane Doe |   50 |
+----------+------+

The query would then return:

+----------+------------+
| sname    | MAX(S.age) |
+----------+------------+
| John Doe |         50 |
+----------+------------+

Now who would need that? John Doe ain’t 50, he’s 30!
As stated in the citation from the book, this is a first attempt to get the name and age of the oldest sailor, in this example, Jane Doe at the age of 50.

SQL would say this query is illegal, but MySQL just proceeds and spits out “garbage”.
Who would need this kind of result?
Why does MySQL allow this little trap for newcomers?

Answer 1

Based on a link which a_horse_with_no_name provided in a comment, I have arrived at my own answer:

It seems that the MySQL way of using GROUP BY differs from the SQL way, in order to permit leaving out columns, from the GROUP BY clause, when they are functionally dependant on other included columns anyways.

Lets say we have a table displaying the activity of a bank account.
It’s not a very thought-out table, but it’s the only one we have, and that will have to do.
Instead of keeping track of an amount, we imagine an account starts at ‘0’, and all transactions to it is recorded instead, so the amount is the sum of the transactions. The table could look like this:

+------------+----------+-------------+
| costumerID | name     | transaction |
+------------+----------+-------------+
|       1337 | h4x0r    |         101 |
|         42 | John Doe |         500 |
|       1337 | h4x0r    |        -101 |
|         42 | John Doe |        -200 |
|         42 | John Doe |         500 |
|         42 | John Doe |        -200 |
+------------+----------+-------------+

It is clear that the ‘name’ is functionally dependant on the ‘costumerID’.
(The other way around would also be possible in this example.)

What if we wanted to know the costumerID, name and current amount of each customer?

In such a situation, two very similar queries would return the following right result:

+------------+----------+--------+
| costumerID | name     | amount |
+------------+----------+--------+
|         42 | John Doe |    600 |
|       1337 | h4x0r    |      0 |
+------------+----------+--------+

This query can be executed in MySQL, and is legal according to SQL.

SELECT costumerID, name, SUM(transaction) AS amount
FROM Activity
GROUP BY costumerID, name

This query can be executed in MySQL, and is NOT legal according to SQL.

SELECT costumerID, name, SUM(transaction) AS amount
FROM Activity
GROUP BY costumerID

The following line would make the query return and error instead, since it would now have to follow the SQL way of using aggregation operations and GROUP BY:

SET sql_mode = 'ONLY_FULL_GROUP_BY';

The argument for allowing the second query in MySQL, seems to be that it is assumed that all columns mentioned in SELECT, but not mentioned in GROUP BY, are either used inside an aggregate operation, (the case with ‘transaction’), or are functionally dependent on other included columns, (the case with ‘name’). In the case of ‘name’, we can be sure that the correct ‘name’ is chosen for all group entries, since it is functionally dependant on ‘costumerID’, and therefore there is only one possibly name for each group of costumerID’s.

This way of using GROUP BY seems flawed tough, since it doesn’t do any further checks on what is left out from the GROUP BY clause. People can pick and choose columns from their SELECT statement to put in their GROUP BY clause as they see fit, even if it makes no sense to include or leave out any particular column.

The Sailor example illustrates this flaw very well.
When using aggregation operators (possibly in conjunction with GROUP BY), each group entry in the returned set has only one value for each of its columns. In the case of Sailors, since the GROUP BY clause is left out, the whole table is put into one single group entry. This entry needs a name and a maximum age. Choosing a maximum age for this entry is a no-brainer, since MAX(S.age) only returns one value. In the case of S.sname though, wich is only mentioned in SELECT, there are now as many choices as there are unique sname’s in the whole Sailor table, (in this case two, John and Jane Doe). MySQL doens’t have any clue which to choose, we didn’t give it any, and it didn’t hit the brakes in time, so it has to just pick whatever comes first, (Jane Doe). If the two rows were switched, it would actually give “the right answer” by accident. It just seems plain dumb that something like this is allowed in MySQL, that the result of a query using GROUP BY could potententially depend on the ordering of the table, if something is left out in the GROUP BY clause. Apparently, that’s just how MySQL rolls. But still couldn’t it at least have the courtesy of warning us when it has no clue what it’s doing because of a “flawed” query? I mean, sure, if you give the wrong instructions to a program, it probably wouldn’t (or shouldn’t) do as you want, but if you give unclear instructions, I certainly wouldn’t want it to just start guessing or pick whatever comes first… -_-‘