Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No it shouldn't.

The verbosity of SQL makes it unwieldy to maintain for pipelines.



Verbosity ?

In the accidental vs essential complexity dimension, it is the most dense language in essential complexity I know (for the value it provides).

This simple command `UPDATE users SET preference = 'blue' WHERE id = 123` virtually contains:

* concurrency control

* statistics, which will help:

* execution plans evaluation, which will reduce IO cost with the help of:

* (several categories of) indexes

* type checking

* data invariants checking

* point in time recovery

* enables dataset-wide backup strategies

* ISO standard way of structuring data

* an interface that empowers business people

And that's just a few items off the top of my mind.

Even APL is less dense. There are no execution plans in APL.


> it is the most dense language in essential complexity I know

QUEL is more dense for equivalent functionality:

   replace users (preference = "blue") where id = 123
Not to mention that it actually adheres to relational calculus, unlike the wild and reckless SQL.

> * type checking

It is only dynamically typed, though, which isn't all that useful. There is good reason why we are seeing static type systems being bolted on to most dynamically typed languages these days (e.g. Typescript). SQL would do well to add the same, but it seems it is seen as a sacred cow that cannot be touched, so I won't hold my breath.*


I use to write complex SQL query very usually, and I can say that it's far more concise than imperative code. Compared to it's own semantics, SQL is actually verbose, but its semantics is so powerful that you gain size.


Please share how many lines of sql it will take to statistically normalize multiple columns. Or even something simple like null cleaning columns based on dynamic thresholds.


For normalization, for instance : Select stddev(col1)/avg(col1), stddev(col2)/avg(col2),... from mytable group by key. One line.


That's just a handful of columns. You have to manually type out each and every arrangement.

Add in if you want the new columns to be added in place and you have to bring in window functions.


Can you expand on what you mean by verbosity here?

I've found that using CTEs has really tightened up my larger SQL queries, and made them a great deal easier to understand and maintain in the future.


Doesn't declarative style of sql make it less verbose than say an imperative style


A lot of SQL is not particularly declarative. You know precisely how you want it to run and you keep writing code until it runs that way.


What do you recommend instead and why?


We have migrated close to 90% of our sql code to Dask/Ray and we could not be happier.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: