Hacker News Reader

Comment by rezonant | Hacker News Reader

While this is very cool, SQL was designed to be used by business people. We need to go back to that model, where we train the business people who need these analytics how to use SQL to uncover the result. That along with a rigorous policy for including the queries that produced the result so the query logic can be checked would go a long way to actually taking advantage of the data we're collecting as businesses.

View on HN

I have been spectacularly unable to get any business people to learn SQL.

I even find that very few will bother with reporting tools (eg Tableau) for simple self-service.

Instead, the expectation is that there will be a programmer/DBA/report writer position dedicated to producing analytics "on-demand."

Yeah, not saying it's easy, or even that it's possible in every case. Most of the time I have failed to get it to happen- but recently I've seen more non-technical stakeholders take it up and use it successfully, so it is possible.

As an engineer myself who likes to dig into data/analytics, writing and tweaking some of the complex SQL is not that easy or fun. I am impatient to get to the insights.

I imagine SQL would be harder and more annoying for biz folks. A programmer might be right "expert" to get the SQL working (Usually the programmer itself is a generalist when trying to write SQL for analytics).

A text-to-SQL tool will help create the queries quickly; it is much easier for an engineer to verify the generated queries and the results of those queries.

My experience is that if you become proficient enough in Tableau or PowerBI, you simply become the go-to guy for those reports. Suddenly senior management starts bombing you with requests for various reports.

But in the end, all roads lead to Excel. No mater what tools you use, someone higher up will still request "But could I get this in Excel?"

Sorry friend, but this is a bit out of touch. Maybe that was the original design intent of SQL, but understanding the application's data model is beyond a lot of sql analysts, much less their business partners.

Hey, no one said it was easy.

> but understanding the application's data model is beyond a lot of sql analysts

You need a better data model or better data analysts (probably the latter).

Putting analysts aside, I do agree though that the data model can be too complex for non-technical stakeholders, but in the vast majority of cases, the data model is simple and stakeholders are looking for basic statistical analysis and trendfinding.

Also, if a moderately skilled human SQL analyst doesn't understand a data model, well GPT has no chance.

But you don't want to do reporting on an application's data model, that doesn't scale: as soon as you have a medium-sized business, the data will not be confined to a single application (unless that application is named SAP). Understanding the business data model is a requirement for SQL analysts anyway, and once you have the application data transformed to the business model, the business users will have no trouble understanding it.

IME, the average SQL/RDBMS technical user doesn't even understand relational data modeling.

They treat it as a bad spreadsheet. JOINs are seen as an annoyance that should be avoided rather than something extremely powerful.

We are far away from average salesperson grasping it.

Thankfully you don't need to design a schema to use it. And while some schemas may indeed be too difficult for non-technical stakeholders dabbling in SQL, I think a huge percentage of them are not

You absolutely need to understand a data schema to write effective (SQL) queries against it.

Reply on news.ycombinator.com