You article was already quoted and I replied

“Functionally Dependent” is really more elaborate explanation of columns in group by - the basics remain the same - you can have the column in the list if there is only one value of that column in the group.

I’m speaking about different case when there are many column value for each group and we just want to define which one is picked.

For example in our example grouping by Country we may also include CountryCode because there is only one for each country, however there are multiple Cities for each Country and group by does not allow to pick which one is selected (or even select it at all in more strict databases)

First Quote, GROUP BY according to SQL92:

“If T is a grouped table, then each [column reference] in each [value expression] that references a column of T shall reference a grouping column or be specified within a [set function specification].”

Second Quote, GROUP BY according to SQL1999 and SQL2003:

“If T is a grouped table, then let G be the set of grouping columns of T. In each [value expression] contained in [select list], each column reference that references a column of T shall reference some column C that is functionally dependent on G or shall be contained in an aggregated argument of a [set function specification] whose aggregation query is QS.”

“In fact ANSI SQL even forbids you to select columns which are not aggregates or part of group by because result in this case is not defined.”

Well, it depends which version of ANSI SQL you are referring too. SQL92 says:

“If T is a grouped table, then each in each that references a column of T shall reference a grouping column or be specified within a .”

Which indeed wants us to always include all non-aggregated columns in the GROUP BY clause.

But SQL1999 and SQL2003 have a more sophisticated view on the matter:

“If T is a grouped table, then let G be the set of grouping columns of T. In each contained in , each column reference that references a column of T shall reference some column C that is functionally dependent on G or shall be contained in an aggregated argument of a whose aggregation query is QS.”

Which just says that you are allowed to include non-aggregated columns in the GROUP BY clause as long as they are completely determined by the GROUP BY clause, in other words, when there is exactly one distinct value per combination of values in the GROUP BY clause.

(http://rpbouman.blogspot.com/2007/05/debunking-group-by-myths.html)

kind regards,

Roland Bouman

Analytical functions are quite helpful but they are generally designed for the different purpose - as you can see they do aggregates but they run on result set not on the grouped result set (which ensures only one row for each group is left)

Or may be I do not see how you can get the same result set as I’m looking for using these functions without too much complications

It surely would be helpful to get them in MySQL.

Sorting table is dangerous trap as if you change query a bit, ie to add range which will be using index to access the rows you will get different plan and not result you’re expecting.

Regarding DISTINCT - applies to the Row rather than the column - it says basically remove duplicate rows.

If you would make it to take argument and read like remove duplicate values from this column you would have same problem as group by - what values you should see for other columns ? This would be hard to define independently on query execution plan.

Yes this is simplification there are other bits in pieces which are allowed but generally if selected column is not dependent on the group by column, like in this case City is not Dependent on Country it either would not be allowed or you could see surprising results in the city column.

That exact article gives good examples and a bit more explanations.

ANSI SQL doesn’t require not aggregated selected columns to be present in GROUP BY in all cases. Here is some elaboration on this:

http://www.oreillynet.com/databases/blog/2007/05/debunking_group_by_myths.html

The issue as I see it thought, is that those queries aren’t actually any GROUP BY queries, but queries where you want the best matching row for a certain WHERE.

Basically MySQL should handle those queries like this:

-Sort by Population
-Scan through the table and
a. if we already took a row with that city, trash it
b. take the city

This can even fully run on indices!

Something like

SELECT DISTINCT( Country ) City, Population, Country FROM City ORDER BY Country, Population DESC

This would pick all all cities with highest population, and sort them by country.

**Sadly enough DISTINCT doesn’t take any arguments.**

I never understood why it doesn’t. Makes no sense to me.