[koolba]

This isn't something you'd expose to your end users right? It seems more targeted for in house analysts.

If that's the case, why would one want to use this vs. having analysts use (or learn) SQL? Typing "Who's the highest paid employee?" looks cool but the equivalent SQL is simple as well. I'm not sure I could necessarily express a more complicated example in a natural language, and even if I could, it wouldn't feel natural.

[davidsQL]

Hey koolba,

Most external users do not know how to code SQL (as well as some SQL developers... hehe). The ability to ask questions in various formats delivers an easy and simple UX.

Use cases include: online banking and credit accounts, Human Resources recruitment staff, executive level officers who have ad-hoc spur of the moment questions, warehouse managers at IKEA.... and the list goes on.

Here are a couple of interesting questions we have encountered in the past: 1. What is the average transaction sum for deals completed in June 2. Who are the top 5 employees with the best salary to sales ratio?

[instakill]

please make the "click here" to experience a demo MUCH more prominent. You're losing out on people playing around with the interface because it's not in plain sight.

[davidsQL]

Are you referring to the Easy Explorer at the download page?

[rpedela]

I see two use cases.

1. Give non-technical people a way to answer their own questions using data in a database which would free up analyst time.

2. Give analysts a way to quickly answer a question and they only have to go to SQL for more complicated questions. It is faster for me to type "who is the highest paid employee" than the equivalent SQL even though the SQL is trivial because I don't have to look up the schema and my fingers are better at typing an English sentence than a SQL query.

[JustUhThought]

That is correct. It is among the super-biggest-huge no-nos to give end users direct access to a d.b. in any form like this.

Even if this has zero bugs and so will never need to change and there are zero security issues and it is sufficiently usable for the end users purposes, just you wait until you need to change the db schema and some user created a report for the ceo based o this and never told anyone about it and now the report is broke and the ceo and cfo are breathing down your neck to "fix it now" because they have a meeti g and need these number (which, now that you are looking at these numbers, they don't even match the numbers in hour db because they derived some of the metrics themselves from raw data rather than using the metric fields from the db, but they did it wrong, so even if you "fix it" you have to break the news that it's still broken and shouldn't be used for their meeting...)

So, correct, this should not be a thing for end users in many cases.