4 ms·
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 ana
by rezonant 4y ago
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.
- jeremyjh 4y agoSorry 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.
- tremon 4y agoBut 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.
- jtdev 4y ago[dead]
- rezonant 4y agoHey, 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.
- clusterhacks 4y agoI 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."
- rezonant 4y agoYeah, 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.
- balaji1 4y agoAs 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.
- TrackerFF 4y agoMy 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?"
- pphysch 4y agoIME, 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.
- rezonant 4y agoThankfully 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
- pphysch 4y agoYou absolutely need to understand a data schema to write effective (SQL) queries against it.