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.
Why you should learn SQL
81–90 of 137 posts
Re: Why you should learn SQL
#82I'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.
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
#83I 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…
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
#84You 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.
Re: Why you should learn SQL
#85Earlier 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/
It's read only, but holy shit please become popular and displace non-ANSI SQL in my life.
Re: Why you should learn SQL
#86I'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…
Re: Why you should learn SQL
#87SQL is an important skill to have, in particular one should learn about database normalization and the normal forms - very important stuff!
Re: Why you should learn SQL
#88I'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/
Re: Why you should learn SQL
#89Earlier 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.
Some rebel about really silly things, such as RDBMS.
Re: Why you should learn SQL
#90Earlier 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…
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.