I strongly feel that if a domain language is not significantly more complex than the domain itself, then the person who is supposed to have domain knowledge should be able to learn the language without much difficulty. I've seen a lot of attempts to build 'simple' analytical systems without SQL, and it works well for simple queries -
but 'business people', when they're smart and motivated, soon start asking more and more specific and detailed questions, with additional conditions and joins - and it soon turns out that SQL is, in fact, an appropriate instrument for complexity that they need.
Your examples seem pretty simple. What about a question like this: how did our 5-week cohort (users that at the time of the event were registered between 4 and 5 weeks) ARPU vary over time and over character class they chose at registration? Is there a statistically significant corellation between participating in any of the 20 custom events we've done in the last half a year and user retention (which must be calculated relative to each users' cohort)?
Of course, a lot of business analysts are moving away from SQL to R, but I doubt that they're after simplicity.
Indeed my examples are simple. However this was the problem: there was no tool around to easily answer those simple questions. Now there is... at least one that fits my arbitrary definitions of what such a tool should do.
Hopefully having a tool to ask these simple queries will give rise to smarter questions, which will either prompt the development of custom dashboards or improvements in the tool itself.
I agree in theory that "business people", if and when they start asking these questions, can and should learn SQL. However my experience seems to point the other way. They'll ask the developer to do more and more reports, eventually hiring someone for the "data analyst" role.
> eventually hiring someone for the "data analyst" role
Oh, I was presuming that a 'business person' and 'data analyst' is the same person. However, usually 'data analyst's job isn't just to write SQL - he's a person who understands the product, marketing, dives into data and researches it, and comes back with actionable insights for the whole business.
And if you're looking for easier scenarios, Excel and it's pivot tables are usually quite enough.
Your examples seem pretty simple. What about a question like this: how did our 5-week cohort (users that at the time of the event were registered between 4 and 5 weeks) ARPU vary over time and over character class they chose at registration? Is there a statistically significant corellation between participating in any of the 20 custom events we've done in the last half a year and user retention (which must be calculated relative to each users' cohort)?
Of course, a lot of business analysts are moving away from SQL to R, but I doubt that they're after simplicity.