We use cookies to ensure you have the best browsing experience on our website. Please read our cookie policy for more information about how we use cookies.
I arrived at essentially the same solution, only instead of your method of counting challenges of hackers found in the Challenges table without a join (which is certainly a clean way to do it), I reused the grouping from the original join—to compare the initially derived count to the counts that are unique—in the second portion of the HAVING/OR statement.
Same cat differently skinned. Sharing since it is more explicit (though admittedly not as efficient) in the hopes it might help anyone stuck on how to arrive at the set of unique counts to include (after including max count achieving hackers).
Note: The DISTINCT clause and c_unique alias are both unnecessary, but are there to keep me sane.
Challenges
You are viewing a single comment's thread. Return to all comments →
I arrived at essentially the same solution, only instead of your method of counting challenges of hackers found in the Challenges table without a join (which is certainly a clean way to do it), I reused the grouping from the original join—to compare the initially derived count to the counts that are unique—in the second portion of the HAVING/OR statement.
Same cat differently skinned. Sharing since it is more explicit (though admittedly not as efficient) in the hopes it might help anyone stuck on how to arrive at the set of unique counts to include (after including max count achieving hackers).
Note: The DISTINCT clause and c_unique alias are both unnecessary, but are there to keep me sane.
Solution is MySQL specific, but easily portable.