3 ms·

Every time I see these layers on top of SQL I think: Just use regular, boring SQL It will be around for a long time, there's an infinite number of resources an

by dewey 8mo ago

Every time I see these layers on top of SQL I think: Just use regular, boring SQL It will be around for a long time, there's an infinite number of resources and examples for it and if you ever have to onboard someone into your code they don't need to learn something new. You can get pretty far by just using CTEs to "pipeline".

data_ders 8mo ago
I'm as big a SQL stan as the next person and I'm also very skeptical anytime anyone says that SQL needs to be replaced. At the same time, it's challenging that SQL cannot be iteratively improved and experimented upon. IMHO, PRQL is a reasonable approach to extending SQL without replacing SQL. But what I'd love to see is projects like Google's zeta-sql [1] and Substrait [2] get more traction. It would provide a more stable, standardized foundation upon which SQL could be improved, which would make the case for "SQL forever" even more strong. I've blogged about this before [3]. [1]: https://github.com/google/googlesql https://github.com/google/googlesql [2]: https://substrait.io/ https://substrait.io/ [3]: https://roundup.getdbt.com/p/problem-exists-between-database-and https://roundup.getdbt.com/p/problem-exists-between-database...
kubb 8mo ago
Complex queries in SQL can quickly get out of control. The fact that you need to replicate the same complex expressions in multiple values that you select or multiple parts of a where clause is bad enough. That there’s no way to pipe the result of a query into another query is just adding insult to injury. (Just create a custom view bro). But if technology competed in quality and not in vendor lock in, we wouldn’t have to deal with C++ or JavaScript.
- tomjakubowski 8mo ago
  DuckDB's "friendly SQL" variant fixes some of these little problems with SQL, including giving the ability to use a column alias in WHERE clauses. https://duckdb.org/docs/stable/sql/dialect/friendly_sql https://duckdb.org/docs/stable/sql/dialect/friendly_sql
itishappy 8mo ago
Does anybody just use "regular, boring SQL" in practice though? All queries I have seen are loaded with regex and other non-standard extensions. Is there even a db vendor that offers full ANSII SQL support? Last I'd checked the answer was no.
- dewey 8mo ago
  In my case I consider Postgres / MariaDB "regular, boring SQL".
  - itishappy 8mo ago
    The problem persists, as Postgres and MariaDB use incompatible SQL dialects, right down to (imo) core concepts such as how to specify an automatically generated primary key.
    - dewey 8mo ago
      I'm aware of that, but what I meant is that they both extended the SQL standard in a similar way and they will have equivalent higher level features like "regex and other non-standard extensions" even if they are not 100% drop-in replacements.
      - itishappy 8mo ago
        Understood. My point is that the underlying concepts are consistent, but the syntax differs between vendors. This largely applies to PRQL as well. Admittedly slightly moreso, but if I already have to learn a new SQL dialect to use postgres, I might not mind learning a nicer one.

by dewey 8mo ago

data_ders 8mo ago

I'm as big a SQL stan as the next person and I'm also very skeptical anytime anyone says that SQL needs to be replaced. At the same time, it's challenging that SQL cannot be iteratively improved and experimented upon. IMHO, PRQL is a reasonable approach to extending SQL without replacing SQL. But what I'd love to see is projects like Google's zeta-sql [1] and Substrait [2] get more traction. It would provide a more stable, standardized foundation upon which SQL could be improved, which would make the case for "SQL forever" even more strong. I've blogged about this before [3]. [1]: https://github.com/google/googlesql https://github.com/google/googlesql [2]: https://substrait.io/ https://substrait.io/ [3]: https://roundup.getdbt.com/p/problem-exists-between-database-and https://roundup.getdbt.com/p/problem-exists-between-database...

kubb 8mo ago

Complex queries in SQL can quickly get out of control. The fact that you need to replicate the same complex expressions in multiple values that you select or multiple parts of a where clause is bad enough. That there’s no way to pipe the result of a query into another query is just adding insult to injury. (Just create a custom view bro). But if technology competed in quality and not in vendor lock in, we wouldn’t have to deal with C++ or JavaScript.

tomjakubowski 8mo ago
DuckDB's "friendly SQL" variant fixes some of these little problems with SQL, including giving the ability to use a column alias in WHERE clauses. https://duckdb.org/docs/stable/sql/dialect/friendly_sql https://duckdb.org/docs/stable/sql/dialect/friendly_sql

itishappy 8mo ago

Does anybody just use "regular, boring SQL" in practice though? All queries I have seen are loaded with regex and other non-standard extensions. Is there even a db vendor that offers full ANSII SQL support? Last I'd checked the answer was no.

dewey 8mo ago
In my case I consider Postgres / MariaDB "regular, boring SQL".
- itishappy 8mo ago
  The problem persists, as Postgres and MariaDB use incompatible SQL dialects, right down to (imo) core concepts such as how to specify an automatically generated primary key.
  - dewey 8mo ago
    I'm aware of that, but what I meant is that they both extended the SQL standard in a similar way and they will have equivalent higher level features like "regex and other non-standard extensions" even if they are not 100% drop-in replacements.
    - itishappy 8mo ago
      Understood. My point is that the underlying concepts are consistent, but the syntax differs between vendors. This largely applies to PRQL as well. Admittedly slightly moreso, but if I already have to learn a new SQL dialect to use postgres, I might not mind learning a nicer one.