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.
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?"
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.
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.
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.
> 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.
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
