Back in October, I spoke at BigData London about how history repeats itself. Clothes, music – even technology.
And now Structured Query Language (SQL) is making a comeback, especially as new database solutions like Snowflake grow in popularity. Yet, at the same time, vendors like Databricks also allow you to execute SQL queries against NoSQL solutions.
Most databases now support SQL, regardless of whether the solution originated as a NoSQL or a classic Relational Database Management System (RDMS) solution. What this means to the experienced developer is that SQL is coming full circle.
The History of SQL
In the early 1970s, IBM experienced a bottleneck with the adoption of their new invention, the relational database. You needed advanced mathematical logic and notation to query the new database, which severely limited its usability. So their researchers, Donald Chamberlin and Raymond Boyce, set out to build a query language that would be accessible to all users. SQL.
Over the decades, SQL became extremely popular with software manufacturers, with many such as DB2, Oracle, PostgreSQL and Sybase adopting SQL as the primary language to interact with their software.
Subsequently, we saw the NoSQL movement and SQL returning to the spotlight. Not to mention the rise and evolution of the internet. But what were the core intentions behind SQL initially? The ability to read and understand the language and make it accessible for all users!
Those IBM’s researchers were definitely on the right track. To achieve adoption, technology must be simple enough to make it accessible to non-technical users.
The limitations of Generated SQL
If you use an analytics product that relies on querying a database, you will be generating and executing queries. Though SQL enables you to query databases, the output is often hard to read and understand. Maybe even impossible… if you are not a machine. Even with SQL growing in popularity again, the original intention behind SQL – to be an accessible interface for all users – has been lost to some extent.
Why does usability matter?
With any data project, adoption is often your number one hurdle. So generating SQL code that is functionally correct but unreadable can result in low usability. And you’ll run into users having difficulty learning and understanding. Or even stop them sharing insights and discussing the data with their team.
You know that collaboration is key in modern BI. And since today’s BI and analytics methods usually comprise BI software, plus Data Scientists running Python or R, and Data Engineers building pipelines and models – you want these groups to talk to each other. They should have the scope to reason about data, build out a better shared understanding of your business and uncover improvements that would otherwise have been lost without collaboration.
Unreadable SQL not only stops those discussions from happening, but it also generates insight silos! The Analyst can’t communicate how they arrived at an insight to a Data Engineer, nor can the Data Engineer reproduce the insights. This results in a loss of trust in the insights. Plus, insight discovery becomes locked within that user group and tool because the team cannot achieve a shared understanding.
Human-readable SQL with Astrato
We generate SQL inside Astrato, and users can interact with every object to view the underlying SQL query that is generated. The difference with our SQL is that it will always be human-readable! We want a Business Analyst to be able to generate a query based on common entities like dimensions, measures, sorting and filtering and then immediately understand the query by reading it!
And the real crux – any person in the organization should be able to understand that query. With Astrato’s human-readable SQL, you’ll soon establish a culture of accessibility, discussion and collaboration around data.
It’s a win-win! For the humans at least!