4 ms·
SQL does have faults but PRQL is not fixing any of those and instead is just a python-esque version that retains all the SQL faults and introduces additional co
by dmz73 4y ago
SQL does have faults but PRQL is not fixing any of those and instead is just a python-esque version that retains all the SQL faults and introduces additional complexity without providing much in return.
Main complaints about SQL are that SELECT comes before FROM and that there are too many dialects.
The SELECT part is only partially valid when writing the query but it is much nicer/easier to read than FROM first options presented elsewhere. This same issue plagues majority of programming languages, most of which optimise for terse syntax that is easy to write but painful to read even when most of the time reading is what people need to do when writing in a programming language.
Dialects is a silly one. Programmers treat databases as interchangeable back end instead of foundation of the data storage. No-one ever even thinks about complaining that you can't swap C for Python or Java without major rewrite yet these languages are nothing but glue between database and UI that SHOULD be interchangeable at any time.
- jeltz 4y agoYeah, SQL has plenty of flaws but PRQL does not seem to be fixing any of those and instead seems to be introducing new issues, e.g. what is up with 'derive country_code = s"LEFT(country, 2)"'.
- eigenrick 4y agoTo my untrained eyes, SQL did not appear to have things like windowing, hierarchical relationships, (trees, graphs) in mind when initially designing the language. Support for these things have been wedged into the language by numerous additions, and I think the fundamental syntactical framework of SQL is cracking under the pressure. Granted, it's been a while since I've had to traverse a tree using SQL, but I do recall that the query was very painful to write, and even more painful to execute efficiently. Also, these things only work if you've wedged your data model into rows and columns. (or you use non-standard language extensions like jsonb) PRQL, on the other hand, rearranges the syntactical structure to be more extensible, and also agnostic over the underlying shape of the data model. It works the same regardless of whether you're using an RDBMS or a graph/document database. Is the result more complicated? IMO, only in the simplest examples. PRQL shines vs SQL when you have multiple stages of aggregation, like pre and post aggregation filtering, or referencing synthesized data, etc.
- ttfkam 4y agoWITH RECURSIVE is how graph/tree queries work in modern SQL (assuming you aren't using something like ltree [0]. The first part of the recursive CTE identifies the root record and then UNION ALL with the subsequent items referencing what came before. Is it as easy as a Cypher query in Neo4j? Not all all. But it is arguably more flexible in that you can represent far more data structures and link to non-graph data easily. I just unwrapped nested JSON columns into a flat key-value set with it last week. It's deceptively powerful. [0] https://www.postgresql.org/docs/current/ltree.html https://www.postgresql.org/docs/current/ltree.html
- LudwigNagasena 4y ago> No-one ever even thinks about complaining that you can't swap C for Python or Java without major rewrite yet these languages are nothing but glue between database and UI that SHOULD be interchangeable at any time. One of the main benefits of Python is that you can easily swap it for C. 95% of the stuff I do in Python every day is only possible due to existence of numpy. And in general programmers care about interop a lot. Interop with C was, obviously, one of the main points of C++. One of the benefits of JVM languages like Kotlin or Scala is simple bidirectional interop with Java. Docker became so popular because you can simply containerize your app and run it anywhere without being tied down to specific requirements of your environment. Etc, etc.