This is getting transpiled to SQL, right? So I still have to understand how the (now generated) SQL will perform on my data and DBMS, plus I got to learn this new syntax. This will be a hard sell.
If that was the end of the story, no transpiled language could ever succeed. But they sometimes do. One could say the very same about e.g. MarkDown which typically renders as HTML, so you still have to understand HTML to a degree. And in the right environment (e.g GitHub repo readmes) you can always fall back to HTML in places where the transpiler support is lacking.
The great thing about transpilers is when they 1) produce tractable, nicely formatted output and 2) you get an 'escape hatch' so you can fall back on the transpilation target. Because then you can always 1) check the output to understand details of an unfamiliar construct, 2) just use the target language in cases where you want to copy-paste a solution written in the target, and 3) just opt out of using the transpiler by using the code it produced as a starting point for your new implementation.
PRQL is not aiming to be an ORM or data layer replacement and is focusing on a specific use case, viz making it simple and ergonomic to write *Analytical Queries*. See the the FAQ [0] for more on this.
In most cases you want to be able to interactively do some data exploration and craft your query as you go along - the sequential flow of PRQL is great for this as you can simply add lines as you go along.
For most people, the RDBMS query optimiser will do a good job of turning the resulting SQL into an optimised query plan. If you need to hand craft the production SQL code for the last few percent of performance, then PRQL gives you full access to the SQL to do that. You probably will still have saved yourself development time by generating the SQL from PRQL in the first place though.
If you're spoiled your friendly neighbourhood DBA will help you there.
The problem I have with these tools is that you then have to reincorporate their optimizations in such a way that the transpiled SQL is identical. If you have to resort to an ORM expression API or raw SQL you gain nothing and are arguably in a worse situation.
SQL query optimisation has been studied since the days IBMers were competing against Quel. If the transpiled SQL has sensible optimisations performance could be equal to or even faster than hand-written SQL. I don't see how this differs from a "language extension" that adds a bit of Pythonic flavour to SQL, which IMO is the right step forward.
DemocracyFTW2|3 years ago
The great thing about transpilers is when they 1) produce tractable, nicely formatted output and 2) you get an 'escape hatch' so you can fall back on the transpilation target. Because then you can always 1) check the output to understand details of an unfamiliar construct, 2) just use the target language in cases where you want to copy-paste a solution written in the target, and 3) just opt out of using the transpiler by using the code it produced as a starting point for your new implementation.
progx|3 years ago
cerved|3 years ago
snthpy|3 years ago
In most cases you want to be able to interactively do some data exploration and craft your query as you go along - the sequential flow of PRQL is great for this as you can simply add lines as you go along.
For most people, the RDBMS query optimiser will do a good job of turning the resulting SQL into an optimised query plan. If you need to hand craft the production SQL code for the last few percent of performance, then PRQL gives you full access to the SQL to do that. You probably will still have saved yourself development time by generating the SQL from PRQL in the first place though.
[0]: https://prql-lang.org/faq/#:~:text=How%20is%20PRQL%20differe...
tjpnz|3 years ago
The problem I have with these tools is that you then have to reincorporate their optimizations in such a way that the transpiled SQL is identical. If you have to resort to an ORM expression API or raw SQL you gain nothing and are arguably in a worse situation.
leohonexus|3 years ago