Live data from Hacker News

Why you should learn SQL

executeprogram.com

81–90 of 137 posts

Re: Why you should learn SQL

#81
post #26

I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. It's like FORTRAN, except FORTRAN has had the decency to stay in use where it's really the best choice. But SQL is out there, like Clippy. "Hey, I see you're collecting some data. SELECT TRUE FROM HELP WHERE COLLECTING_DATA IS TRUE

Nobody else has invented any other declarative language it seems. Come on aspiring post-docs, do your thing and launch a new programming language. If MIT can launch Julia someone can launch a language that's not SQL.

Edgeql is trying.

Re: Why you should learn SQL

#82

I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. It's like FORTRAN, except FORTRAN has had the decency to stay in use where it's really the best choice. But SQL is out there, like Clippy. "Hey, I see you're collecting some data. SELECT TRUE FROM HELP WHERE COLLECTING_DATA IS TRUE

SQL may look ugly but it got the fundamentals correct. It's sort of like Git in that way. SQL is hard to replace because most replacements are either not radical enough to make migration worth it or so radical that it's something else entirely.

The problem with SQL is that it doesn’t have the fundamentals correct — it doesn’t compose well, the language is an arbitrary hodgepodge of keywords, it conflates data administration with data manipulation/retrieval, it runs a ternary logic under boolean terms — leading to both potential for false negatives and false positives, it lacks a real standard (it has one, but it standardizes very little, and gets extended arbitrarily), it lacks any useful standard for libraries — causing your choice of DB to essentially also be your choice of standard library.

As a language, SQL is a downright mess. The only thing it really got right was being based on the relational algebra and model.

It’s also why language tooling is utter garbage is the DBA world. The lack of real Autocorrect/suggestion, code formatters, useful error messages, static typing (the tables & views are strictly typed, but your queries can’t be?), the lack of interoperability, etc all stem from how awful SQL is at being a programming language. Jumping from C# to SQL is like viewing a portal into the 80’s — it’s ridiculous. Hell, the standard itself is behind a damned paywall. If that’s not a signal of something going horribly wrong, I don’t know what is

What I’ve never understood is why open source databases don’t have alternative frontends to SQL — where’s my first-class support for datalog in Postgres? Or even just a SQL dialect that lets me put FROM before SELECT so autocomplete can do something useful for once?

Re: Why you should learn SQL

#83

I just keep getting faster at SQL. It's fun. I used CROSS LATERAL JOIN last night to find the nearest regions to points. Super fast and easy: https://carto.com/blog/lateral-joins/ . Right on the data. SQL does change over time, as Postgres adds features, but especially when you use MADlib, Postgis, and other extensions. I mean ... https://postgis.net/docs/reference.html . And everything I learned when I started is st…

I just want to throw out there, one of the weaknesses I've seen is the lack of fast options for pivoting (wide long). I've used the tablefunc module: https://www.postgresql.org/docs/13/tablefunc.html but it's not particularly fast in my experience (maybe they've improved it since it has been awhile) and the syntax is a bit odd. I'm spoiled with R (newer version) tidyr's pivot_wider and pivot_longer.

Gosh, yes it's been awhile. I posted this, ahem, over 8 years ago: https://stackoverflow.com/questions/15415446/pivot-on-multip.... Guess what, while to many things change, I still use SQL.

I should, uh, try it again. Or try PL/R, PL/Python, or PL/pgsql. There are options.

Re: Why you should learn SQL

#84

You should learn SQL because it's likely to be a very different language to the ones you already know. In SQL you don't tell the DB how to get the data (for loops and pointers) but what the result should look like, and the DB figures out an execution plan. This style is well worth practising and appreciating.

When I first encountered SQL i hated it as a language. But then the more I understood the working of RDBMS the more I appreciated its use cases. ETL is probably best handled by the DB if you don't want to get down into optimising the ETL process. I feel having tight loops in SQL and having another programming language as a glue between them is a decent tradeoff but you have to keep data transfer in mind.

Re: Why you should learn SQL

#85
post #35
post #26

Earlier quoted context omitted.

Nobody else has invented any other declarative language it seems. Come on aspiring post-docs, do your thing and launch a new programming language. If MIT can launch Julia someone can launch a language that's not SQL.

Like Kusto? https://docs.microsoft.com/en-us/azure/data-explorer/kusto/c... https://docs.microsoft.com/en-us/azure/data-explorer/

Hmm.

It's read only, but holy shit please become popular and displace non-ANSI SQL in my life.

Re: Why you should learn SQL

#86

I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. It's like FORTRAN, except FORTRAN has had the decency to stay in use where it's really the best choice. But SQL is out there, like Clippy. "Hey, I see you're collecting some data. SELECT TRUE FROM HELP WHERE COLLECTING_DATA IS TRUE

> I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. So, if we put aside Clippy jokes and so on, what's your problem with SQL exactly and what does "better than SQL" mean to you? Because what I saw in the last couple of decades is the NoSQL movement lose air, and half the products representing it adding some sort of SQL dialect support, which if you th…

When I heard "NoSQL", I thought we were getting an alternative query language for working with relational data, not throwing away the entire concept of RBMS's.

Re: Why you should learn SQL

#87

SQL is an important skill to have, in particular one should learn about database normalization and the normal forms - very important stuff!

SQL is a query language. Data normalization is a relational design methodology. They aren’t actually related except that relational databases often use SQL and benefit from normalization. You can normalize data models without SQL and you can use SQL to interact with denormalized data.

Re: Why you should learn SQL

#88

I'd like to see SQL as a first class citizen in a static typed language with tuples & record polymorphism. disclaimer: I hate ORMs. Something of interest: https://smlsharp.github.io/en/

Wow I've been digging into the ML languages these last few months. First time I heard of SMLSharp. Looks very good :)

Re: Why you should learn SQL

#89
post #86

Earlier quoted context omitted.

> I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. So, if we put aside Clippy jokes and so on, what's your problem with SQL exactly and what does "better than SQL" mean to you? Because what I saw in the last couple of decades is the NoSQL movement lose air, and half the products representing it adding some sort of SQL dialect support, which if you th…

When I heard "NoSQL", I thought we were getting an alternative query language for working with relational data, not throwing away the entire concept of RBMS's.

Every generation wants to rebel about something.

Some rebel about really silly things, such as RDBMS.

Re: Why you should learn SQL

#90
post #49

Earlier quoted context omitted.

And even if you don't want to normalize, at least don't make the DB basically incomprehensible. Speaking from experience, a "abnormalized" db sucks. https://news.ycombinator.com/item?id=27842820

There's reasons for one wide table. The traditional SQL database uses row based data structures. When you shift to columnar data formats for the table, parquet or any columnar DB, the normalization rules which were developed for row based become extremely different. The brave new world now is in-memory DBs. All those 1970s rules, which make sense for row based tables stored on disk, don't apply to data in RAM. At all…

This is a common misconception.

Columnar stores do indeed enable wide tables but they don’t replace the need for normalization or the benefits. Wide tables and normalization (or denormalization) solve different problems.

From the perspective of a database the difference between RAM and disk is latency. Normalization is still a factor in query performance.

Post reply on HN