5 ms·

SQL is good enough and well established, i see no need for another sql wrapper with a different syntax.

datadrivenangel 3y ago
There are benefits to improving SQL when you have to maintain hundreds of SQL files for a pipeline.
setr 3y ago
In the world of application languages, we accept that many languages can exist and compete, and serve various needs and improvements. And we curse the alternative, like that the browser forces us into a single language — JS. In the world of RDBMS languages, we say there is SQL, and only SQL, and none other need ever exist. Ignoring that the SQL standard defines more of an aesthetic of the language than anything actually useful, so you’re only ever dealing with incompatible dialects anyways — there is no one SQL language in practice. Somehow the only way to consider any possible alternative is to drop the relational model altogether, throwing the baby out with the bathwater. I feel like DBA’s have managed to get themselves stuck in the 80’s in terms of tooling; the glory of Codd squirreled away in this great fear of changing anything at all. COBOL is derided by all, and SQL praised unquestionably — I don’t know where it all went wrong
- nerdponx 3y ago
  I think the concern is more that database engines themselves have a wide range of supported features and functionality, and the variations in SQL mostly reflect the variations in the supported feature set. Developers have also found themselves burned for decades by trying to interact with databases in languages that aren't SQL, including and especially various DSLs and ORM frameworks. The skepticism level is high because the track record for SQL alternatives/replacements isn't good. Maybe PRQL is the one that finally succeeds, but the lack of success until this point is not for lack of trying or imagination.
  - setr 3y ago
    > variations in SQL mostly reflect the variations in the supported feature set I mean, the notion of modifying the language itself to enable various features is a kind of psychosis not seen in decades in the application-language universe -- functions becoming keywords, and flags becoming keywords, and keywords injected randomly for english-ness [TRIM(LEADING "c" FROM col)] is generally absurd. For the most part, these should be modules/libraries/etc but SQL defines an aesthetic, and that aesthetic is a smattering of new keywords for every feature/function. > Developers have also found themselves burned for decades by trying to interact with databases in languages that aren't SQL, including and especially various DSLs and ORM frameworks. I think the fundamental issue here for DSLs is that at the end of the day, they're all compile-to-SQL languages, because the database does not offer any other API than SQL. And the general confusion is that SQL pretends to be standardized, so DSLs try to support all the databases, and end up implementing only some minimal shared subset... no matter how nice the DSL might be, you end up having to leave it anyways. ORMs are a different story; they're not just trying to hide the SQL language, they're trying to hide the relational model itself, and the vast majority of issues you have revolve around that object-relational mismatch. If one gets turned off by the mismatch, fixes it by writing raw SQL directly, and avows to never not-write SQL again (including the avoidance of query builders), then I don't know. They've conflated the two unnecessarily. But if you admit to query-builders being useful (and I demand you must; who could look at C# LINQ and think "nah, I LIKE smashing strings together and carefully administering the correct number of commas and precise ordering of clauses"?), then you admit to the possibility a better API exists. > Maybe PRQL is the one that finally succeeds, but the lack of success until this point is not for lack of trying or imagination. The fundamental confusion I have is that looking at other systems with fancy underlying engines, you would typically see a division between the API/language interface and the engine itself -- the frontend, and backend. And the frontend may be swapped out cleanly. Erlang/Elixer both sit on BEAM. Java/Scala/Clojure sit on the JVM. But an RDBMS vendor will only ever implement and support the singular dialect of SQL; there is nothing else. They'll probably implement support for app-language support for procedural logic (mssql has language extensions, postgres has PL/*, etc), but to execute actual database commands you end up submitting... SQL. There is nothing else. It's intimately (and afaik unnecessarily) tied to database engine, and I don't really understand why. And anyone who tries to do anything different must do so as a compile-to-SQL, and inherit all of the issues of transpilation and the underlying language itself. I could understand it as market forces, except even our one hope for good in the database world, postgres, makes the same choice
- zokier 3y ago
  As a tangent, I have this same complaint about how regex are perceived, except the situation is even worse. At least SQL is actually designed, standardized and somewhat readable. In comparison the familiar regex syntax has been organically brewing, from simple kleene star to the impenetrable linenoise it is today, with no rhyme or reason. I know there has been some movement to create new regex languages[1] but like PRQL they are very niche. [1] https://github.com/pomsky-lang/pomsky https://github.com/pomsky-lang/pomsky comes to mind, no endorsement
pie_flavor 3y ago
Are you familiar with what the SQL for the following PRQL looks like? from employees group role ( sort join_date take 1 ) It's pretty complicated and annoying. There's loads of attempts to reinvent SQL, but PRQL is the only one that's designed for what SQL is actually for, and fixes real problems instead of 'ick' problems.
- jeroen79 3y ago
  no, i can't read PRQL, and a have no interest in learning it, it also doesn't really matter if it is a few lines more, if that means more people can read and understand it.
- _dain_ 3y ago
  something like select * from employees qualify row_number() over ( partition by role order by join_date ) = 1 although I don't disagree with you. and `qualify` isn't standard SQL iirc
  - pie_flavor 3y ago
    Right, if you don't have QUALIFY you need a nested SELECT with named outputs within a WITH. (The example is taken from the website.)

There are benefits to improving SQL when you have to maintain hundreds of SQL files for a pipeline.

setr 3y ago

In the world of application languages, we accept that many languages can exist and compete, and serve various needs and improvements. And we curse the alternative, like that the browser forces us into a single language — JS. In the world of RDBMS languages, we say there is SQL, and only SQL, and none other need ever exist. Ignoring that the SQL standard defines more of an aesthetic of the language than anything actually useful, so you’re only ever dealing with incompatible dialects anyways — there is no one SQL language in practice. Somehow the only way to consider any possible alternative is to drop the relational model altogether, throwing the baby out with the bathwater. I feel like DBA’s have managed to get themselves stuck in the 80’s in terms of tooling; the glory of Codd squirreled away in this great fear of changing anything at all. COBOL is derided by all, and SQL praised unquestionably — I don’t know where it all went wrong

nerdponx 3y ago
I think the concern is more that database engines themselves have a wide range of supported features and functionality, and the variations in SQL mostly reflect the variations in the supported feature set. Developers have also found themselves burned for decades by trying to interact with databases in languages that aren't SQL, including and especially various DSLs and ORM frameworks. The skepticism level is high because the track record for SQL alternatives/replacements isn't good. Maybe PRQL is the one that finally succeeds, but the lack of success until this point is not for lack of trying or imagination.
- setr 3y ago
  > variations in SQL mostly reflect the variations in the supported feature set I mean, the notion of modifying the language itself to enable various features is a kind of psychosis not seen in decades in the application-language universe -- functions becoming keywords, and flags becoming keywords, and keywords injected randomly for english-ness [TRIM(LEADING "c" FROM col)] is generally absurd. For the most part, these should be modules/libraries/etc but SQL defines an aesthetic, and that aesthetic is a smattering of new keywords for every feature/function. > Developers have also found themselves burned for decades by trying to interact with databases in languages that aren't SQL, including and especially various DSLs and ORM frameworks. I think the fundamental issue here for DSLs is that at the end of the day, they're all compile-to-SQL languages, because the database does not offer any other API than SQL. And the general confusion is that SQL pretends to be standardized, so DSLs try to support all the databases, and end up implementing only some minimal shared subset... no matter how nice the DSL might be, you end up having to leave it anyways. ORMs are a different story; they're not just trying to hide the SQL language, they're trying to hide the relational model itself, and the vast majority of issues you have revolve around that object-relational mismatch. If one gets turned off by the mismatch, fixes it by writing raw SQL directly, and avows to never not-write SQL again (including the avoidance of query builders), then I don't know. They've conflated the two unnecessarily. But if you admit to query-builders being useful (and I demand you must; who could look at C# LINQ and think "nah, I LIKE smashing strings together and carefully administering the correct number of commas and precise ordering of clauses"?), then you admit to the possibility a better API exists. > Maybe PRQL is the one that finally succeeds, but the lack of success until this point is not for lack of trying or imagination. The fundamental confusion I have is that looking at other systems with fancy underlying engines, you would typically see a division between the API/language interface and the engine itself -- the frontend, and backend. And the frontend may be swapped out cleanly. Erlang/Elixer both sit on BEAM. Java/Scala/Clojure sit on the JVM. But an RDBMS vendor will only ever implement and support the singular dialect of SQL; there is nothing else. They'll probably implement support for app-language support for procedural logic (mssql has language extensions, postgres has PL/*, etc), but to execute actual database commands you end up submitting... SQL. There is nothing else. It's intimately (and afaik unnecessarily) tied to database engine, and I don't really understand why. And anyone who tries to do anything different must do so as a compile-to-SQL, and inherit all of the issues of transpilation and the underlying language itself. I could understand it as market forces, except even our one hope for good in the database world, postgres, makes the same choice
zokier 3y ago
As a tangent, I have this same complaint about how regex are perceived, except the situation is even worse. At least SQL is actually designed, standardized and somewhat readable. In comparison the familiar regex syntax has been organically brewing, from simple kleene star to the impenetrable linenoise it is today, with no rhyme or reason. I know there has been some movement to create new regex languages[1] but like PRQL they are very niche. [1] https://github.com/pomsky-lang/pomsky https://github.com/pomsky-lang/pomsky comes to mind, no endorsement

pie_flavor 3y ago

Are you familiar with what the SQL for the following PRQL looks like? from employees group role ( sort join_date take 1 ) It's pretty complicated and annoying. There's loads of attempts to reinvent SQL, but PRQL is the only one that's designed for what SQL is actually for, and fixes real problems instead of 'ick' problems.

jeroen79 3y ago
no, i can't read PRQL, and a have no interest in learning it, it also doesn't really matter if it is a few lines more, if that means more people can read and understand it.
_dain_ 3y ago
something like select * from employees qualify row_number() over ( partition by role order by join_date ) = 1 although I don't disagree with you. and `qualify` isn't standard SQL iirc
- pie_flavor 3y ago
  Right, if you don't have QUALIFY you need a nested SELECT with named outputs within a WITH. (The example is taken from the website.)