MySQL is a database that has been bending the SQL standard in ways that make it hard to move off MySQL. What may appear to be a clever technique for vendor lockin (or maybe just oversight of the standard) can be quite annoying in understanding the real meaning of the SQL language.
One such example is
MySQL’s interpretation of how GROUP BY
works. In MySQL, unlike any other database, you can put arbitrary expressions into your
SELECT
clause, even if they do not have a formal dependency on the
GROUP BY
expression. For instance:
SELECT employer, first_name, last_name
FROM employees
GROUP BY employer
This will work in MySQL, but what does it mean? If we only have one resulting record per
employer
, which one of the employees will be returned? The semantics of the above query is really this one:
SELECT employer, ARBITRARY(first_name), ARBITRARY(last_name)
FROM employees
GROUP BY employer
If we assume that there is such an aggregation function as
ARBITRARY()
. Some may claim that this can be used for some clever performance “optimisation”. I say: Don’t. This is so weakly specified, it is not even clear if the two references of this pseudo-
ARBITRARY()
aggregate function will produce values from the same record.
Just look at the number of Stack Overflow questions that evolve around the
“not a GROUP BY expression” error:
I’m sure that parts of this damage that has been caused to a generation of SQL developers is due to the fact that this works in
some databases.
ONLY_FULL_GROUP_BY
But there is a flag in MySQL called
ONLY_FULL_GROUP_BY
, and
Morgan Tocker, the MySQL community manager suggests eventually turning it on by default.
MySQL community members tend to agree that this is a good decision in the long run.
While it is certainly very hard to turn this flag on for a legacy application, all new applications built on top of MySQL should make sure to turn on this flag. In fact, new applications should even consider turning on
“strict SQL mode” entirely, to make sure they get a better, more modern SQL experience.
For more information about MySQL server modes, please consider the manual:
https://dev.mysql.com/doc/refman/5.7/en/sql-mode.htmlLike this:
Like Loading...
Published by lukaseder
I made jOOQ
View all posts by lukaseder
Sure, MySql without the strict mode is a mess. However, this ARBITRARY would be a useful function:
1. Sometimes you really don’t care which
first_name
you get. Maybe you’re just inspecting the data, rather than writing production code.2. It saves you from repeating all the columns if
first_name
andlast_name
are functions ofemployer
(i.e.,employer
is a unique key or the table is denormalized).3. Sometimes, even if none the above holds, you may be satisfied with an arbitrary result. Once, I had a table, where there were various (mis)spellings of “first_name” for one
employer
. I could not fix it as the table had to exactly represent imported data and in the result I needed a unique “employer”. So I resorted toMIN
, wherebyARBITRARY
would do.If
ARBITRARY
guaranteed to return correspondingfirst_name
andlast_name
, it would provide a new functionality.Note that there are other cases when the SELECT is non-deterministic (e.g., incomplete ORDER BY).
Yes, I agree. The SQL standard refers to the
SOME
orANY
aggregate functions, named consistently with the quantified comparison predicate keywords:SOME
andANY
appeared in SQL:1999. I haven’t seen this in the wild yet, though…When I’m just casually browsing data, I often use GROUP_CONCAT() to full see the set of values that match.
As Lukas mentions, there is an any value function:
http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_any-value
ANY_VALUE() is also helpful to retrofit to queries where the illegal column grouping is not known to cause application problems, and there is a desire to change the sql mode to be strict.
Interesting! I wasn’t aware of that function – thanks for sharing. Too bad it’s not simply called
ANY
, it would make MySQL the only database I’m aware of that implements this SQL standard aggregate function (see my comment) :)> Too bad it’s not simply called ANY
Too bad, you can’t simply write
val ANY = ANY_VALUE;
to get what you want. ;)
Are you trolling, now? ;-)
Actually, no. I really wonder, if there could be an language offering what SQL does without its rigidity. Something based on “standard” programming constructs with all its flexibility rather than pseudo-English sentences and tons of keywords.
It would probably be incredibly hard to implement declarative programming (i.e. cost-based optimisers and execution planners), once you’d make SQL a “standard” programming language… Or to put it in Winston Churchill’s words:
ANY_WAY()
… (lame pun), I think we should implement support for that in jOOQ via https://github.com/jOOQ/jOOQ/issues/3798.For MySQL, this would be natively supported. In other databases, we can still resort to
MAX()