6 ms·

SQL is around since the dawn of relational database and its hard to replace. The best option for mass adoption is to have drag and drop tools with visualization

SQL is around since the dawn of relational database and its hard to replace. The best option for mass adoption is to have drag and drop tools with visualizations like no-code ETL. Template like and markup language or framework are easier to adopt for new developers but majority of the population still tend of stick with the original language.

Cyberdog 4y ago
Code source control is a vital aspect of software development in the modern era, and no-code tools are incompatible with that unless they are also able to output their representations as plain code so that tools like "diff" work as expected, in which case you might as well stick to SQL.
- Digit-Al 4y ago
  That is so true! Have you ever used SSIS? A really powerful tool, but even small changes can cause hundreds of changes in the underlying XML, which makes change control a nightmare. Forget branching and merging anything other the most minor changes.
- pasc1878 4y ago
  That is a limitation of text based tools. There have been code source control tools based on the AST see Envy for Smalltalk. Hopefully eventually we will dump the limitations of text based tools and use one based on the structure of programs. I don't want to know line 123 has changed I want to know that function fn in module m has changed or that function X was added on this date.
summerlight 4y ago
Because of this reason, vast majority of new generation query languages are translated into SQL but in fact it is not a great language as a target language. I think SQL should more focus on features as an efficient intermediate language rather than adding more and more ad hoc "convenient" features that don't really play well with other language features...
steve_g 4y ago
If we still use math 100 years from now, we'll still use SQL. It's a fine way to query relational data, and relational data is a fine way to model reality. I'd like to hear from people that think I'm wrong.
- anon84873628 4y ago
- randomdata 4y ago
  > If we still use math 100 years from now, we'll still use SQL. Those are incongruent. Do you mean Western notation? > It's a fine way to query relational data It's quirky, but good enough for ad-hoc queries that I think it will be hard to overcome the momentum in that area. It's not fine for application work, where you need things like composition. We've tried to solve those problems with ORMs, but the ORM is starting to fall out of fashion due to a number of problems of its own. SQL is not a great compiler target. I do eventually see something lower level built for programmers, not data analysts, rising up here. If SQL is compared to Javascript, something akin to WASM, perhaps.
  - munk-a 4y ago
    ORMs, when best used (and we use them even though we're pretty SQL literate and maintain a lot of SQL) will survive forever, nothing beats an ORM for really dirt simple expressions that you want to be trivially testable. Never in my life do I want to see someone write an UPDATE query against a single table with no shenanigans with dynamic field support using string gluing to properly stitch in all the columns - this is something a known tool can do better, this is a great opportunity for an ORM. A non-great opportunity for an ORM is anything I'd call a "report query" (some complex read-only query involving a lot of JOINs, a bunch of WHERE clauses and possibly some nested aggregation for funsies) - this is where you pull out the SQL (or alternative query language!) because an ORM will struggle to properly support all the functionality you need and because trying to tune a query being produced by an ORM (even just to make sure it's well aligned with logical indices) is a task that yields nothing but endless frustration.
randomdata 4y ago
> SQL is around since the dawn of relational database There was a decent amount of competition back then, though. It seems the industry eventually settled on SQL to be compatible with Oracle's dominance. Postgres didn't gain SQL support until about a decade in.
- onlyrealcuzzo 4y ago
  What were some of the alternatives? What did Postgres start with?
  - randomdata 4y ago
    Postgres used QUEL in the early days, as did its predecessor Ingres. MRDS, the first commercially available relational database, used a language known as Linus. Alpha was the language originally envisioned by Codd to describe his relational model.
munk-a 4y ago
> The best option for mass adoption is to have drag and drop tools with visualizations like no-code ETL. No. I've worked with BI tools and when things get complicated you end up needing to go back to text to express the weird bits and every company has a few queries with weird bits in it. I also will gladly agree that it's network effect is what makes it so hard to replace (as opposed to some perceived perfection of the language - it definitely isn't perfect) but SQL has evolved significantly over time. Core SQL hasn't - but Postgres in particular has pushed the envelope on what can be done with WINDOWs, CTEs, and aggregate modifiers. I think it's a bit misleading to say the majority of the population still tend to stick with the original language since, at a previous job we did attempt to write "neutral SQL" that would execute on MSSQL, Postgres and MySQL - but in most shops you'll have a chosen dialect and you'll be able to make use of more recent and advanced language features... So the majority of the population is using modern SQL just like the majority of programmers that'd describe themselves C/C++ programmers can't grok ANSI C.

Cyberdog 4y ago

Code source control is a vital aspect of software development in the modern era, and no-code tools are incompatible with that unless they are also able to output their representations as plain code so that tools like "diff" work as expected, in which case you might as well stick to SQL.

Digit-Al 4y ago
That is so true! Have you ever used SSIS? A really powerful tool, but even small changes can cause hundreds of changes in the underlying XML, which makes change control a nightmare. Forget branching and merging anything other the most minor changes.
pasc1878 4y ago
That is a limitation of text based tools. There have been code source control tools based on the AST see Envy for Smalltalk. Hopefully eventually we will dump the limitations of text based tools and use one based on the structure of programs. I don't want to know line 123 has changed I want to know that function fn in module m has changed or that function X was added on this date.

summerlight 4y ago

Because of this reason, vast majority of new generation query languages are translated into SQL but in fact it is not a great language as a target language. I think SQL should more focus on features as an efficient intermediate language rather than adding more and more ad hoc "convenient" features that don't really play well with other language features...

steve_g 4y ago

If we still use math 100 years from now, we'll still use SQL. It's a fine way to query relational data, and relational data is a fine way to model reality. I'd like to hear from people that think I'm wrong.

anon84873628 4y ago
randomdata 4y ago
> If we still use math 100 years from now, we'll still use SQL. Those are incongruent. Do you mean Western notation? > It's a fine way to query relational data It's quirky, but good enough for ad-hoc queries that I think it will be hard to overcome the momentum in that area. It's not fine for application work, where you need things like composition. We've tried to solve those problems with ORMs, but the ORM is starting to fall out of fashion due to a number of problems of its own. SQL is not a great compiler target. I do eventually see something lower level built for programmers, not data analysts, rising up here. If SQL is compared to Javascript, something akin to WASM, perhaps.
- munk-a 4y ago
  ORMs, when best used (and we use them even though we're pretty SQL literate and maintain a lot of SQL) will survive forever, nothing beats an ORM for really dirt simple expressions that you want to be trivially testable. Never in my life do I want to see someone write an UPDATE query against a single table with no shenanigans with dynamic field support using string gluing to properly stitch in all the columns - this is something a known tool can do better, this is a great opportunity for an ORM. A non-great opportunity for an ORM is anything I'd call a "report query" (some complex read-only query involving a lot of JOINs, a bunch of WHERE clauses and possibly some nested aggregation for funsies) - this is where you pull out the SQL (or alternative query language!) because an ORM will struggle to properly support all the functionality you need and because trying to tune a query being produced by an ORM (even just to make sure it's well aligned with logical indices) is a task that yields nothing but endless frustration.

randomdata 4y ago

> SQL is around since the dawn of relational database There was a decent amount of competition back then, though. It seems the industry eventually settled on SQL to be compatible with Oracle's dominance. Postgres didn't gain SQL support until about a decade in.

onlyrealcuzzo 4y ago
What were some of the alternatives? What did Postgres start with?
- randomdata 4y ago
  Postgres used QUEL in the early days, as did its predecessor Ingres. MRDS, the first commercially available relational database, used a language known as Linus. Alpha was the language originally envisioned by Codd to describe his relational model.

munk-a 4y ago

> The best option for mass adoption is to have drag and drop tools with visualizations like no-code ETL. No. I've worked with BI tools and when things get complicated you end up needing to go back to text to express the weird bits and every company has a few queries with weird bits in it. I also will gladly agree that it's network effect is what makes it so hard to replace (as opposed to some perceived perfection of the language - it definitely isn't perfect) but SQL has evolved significantly over time. Core SQL hasn't - but Postgres in particular has pushed the envelope on what can be done with WINDOWs, CTEs, and aggregate modifiers. I think it's a bit misleading to say the majority of the population still tend to stick with the original language since, at a previous job we did attempt to write "neutral SQL" that would execute on MSSQL, Postgres and MySQL - but in most shops you'll have a chosen dialect and you'll be able to make use of more recent and advanced language features... So the majority of the population is using modern SQL just like the majority of programmers that'd describe themselves C/C++ programmers can't grok ANSI C.