Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
Clever. This avoids the duplicate modifiedStrength formula, circumventing an SQL quirk.
Beautifully concise. I like how you simplified by realizing that the 2 x 2 case does not need special treatment. We can just make a 1 x 1 matrix the base case and recurse from there. The 2 x 2 behavior is implied in the general case.
The general case is concise to the point of being difficult to read and understand.
A solid solution because unlike all the others I have seen, it does not hardcode the employee IDs of Mike and Jon.
To be 'the optimal one', I believe it would need to resolve the assumption that the staff ID of the payment matches the store manager ID, which is not necessarily true. In other words, the query should register each payment under the manager matching the payment's store ID, not the staff matching the payment's staff ID. This would make the query much more complicated.
The kata forces a solution using IN without DISTINCT. I am wondering about the underlying reasoning for the prescribed solution.
I would think that using DISTINCT would improve performance as well as clarify intent - we are only interested in distinct department IDs matching our sales conditions.
Some people are pointing out that a JOIN instead of IN is a best practice. As I understand it though, a JOIN would be far less performant because it enumerates all possible combinations of departments and sales? So if we have D departments and S sales, a join would be O(D * S) while a nested IN would be O(D + S). So perhaps the kata is trying to instruct us on how IN can be used as a performant alternative to JOIN?
Ah, but this is part of the standard library, not a 3rd party framework. I think this makes all the difference in the world. Once we import a 3rd party framework, we also import the concept of dependency management and the many issues that accompany it. But standard library features are freebies.
Just when I thought my one-liner could not be beaten! This is the best solution because reusing a built-in capability is preferable to reinventing it.
Extremely performant solution with intuitively named variables