4 ms·
It's not very good from prql devs to use artificially bloated (line wise) examples to show SQL is bad. from employees select {id, first_name, age} sor
by bvrmn 3y ago
It's not very good from prql devs to use artificially bloated (line wise) examples to show SQL is bad.
from employees
select {id, first_name, age}
sort age
take 10
vs
SELECT
id,
first_name,
age
FROM
employees
ORDER BY
age
LIMIT
10
Huh? For simple queries SQL is simple. You can't beat it on this field.
- aerzen 3y agoYeah, we use an SQL formatter that is a bit too verbose for most tastes. But I do agree, PRQL is not really needed for simple queries - it starts to shine only when you have 5+ transforms (clauses).
- bdcravens 3y agoI'd love to see good examples of joining across several tables and applying aggregates. These are the types of queries that are a bit tedious to write but where SQL really provides value vs other ways of storing and extracting data.
- timClicks 3y agoThis style of formatting makes more sense when queries become larger. It's also quite good when you want to have readable diffs to review when queries change.
- bvrmn 3y agoSame reasoning then should be applied for PRQL. My issue is unfair depiction of PRQL as "simple" and "concise". BTW most modern differs show changed parts of line which really helps not to bother with diff-friendly formatting.