4 ms·

Hot takes: SQL is great, actually. This thing isn't better.

• breakfastduck 4y ago
  As much as I love SQL it can often be a pain and involve lots of nested subqueries to do 'simple' things. I like this way this abstracts it. Would I use this instead of proper SQL in a data warehouse / large app? Maybe not. Would I use it to manually query DBs when I need some ad hoc info? For sure.
  • notimportant0 4y ago
    If this becomes a full-fledge DQL that can be used in a proc or function in a running Postgres instance, I would use it in production.
• mellosouls 4y ago
  No, but it's not as foreign a paradigm or language to (presumably?) its main target audience - developers.
• catchclose8919 4y ago
  Not sure if this is better, but SQL is HORRIBLE... we probably put up with it bc it's based on sane math & theory, and we almost never write it by hand. There's zero thought to any kind of ergonomics, there's no way to say "join table Y but prefix all its columns with employee_", it's expressed backwards ffs (instead of starting with FROM), results of queries with joins are forced to be flat tables and there's no way to get trees as you need 99% in app code - all the repetitve app code to "nest" entities in results that also needs to make brittles assumptions about ordering and uniqueness because people couldn't standardize on a "RESULT AS TREE [NESTING <Y> INTO <X>]" clause or smth. equivalent etc. etc. PRQL though seems to also lack all the essetial features you would expect around joins. Suff like Arrango DB's AQL seems to be a nice example of adding the missing feature to SQL, probably more of the need to accomodate graph data too, but it actually solves SQLs problems even in relational contexts - see https://www.arangodb.com/docs/stable/aql/tutorial-join.html#merging-characters-and-traits https://www.arangodb.com/docs/stable/aql/tutorial-join.html#... .