Why you should learn SQL • Hacker News Board

Re: Why you should learn SQL

#131

Post by cratermoon » Wed, Aug 04, 2021, 10:01 PM UTC

BulgarianIdiot wrote: post #64

cratermoon wrote: post #23

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…

- actual abstract data types

- object (or rather, tuple) identity

- replace null with something to indicate missing or unknown. Have sensible null object behavior

And the big one that gives every relational algebra purist fits: make graph theory a first-class citizen of the data model.

Re: Why you should learn SQL

#132

Post by cratermoon » Thu, Aug 05, 2021, 2:27 AM UTC

BulgarianIdiot wrote: post #89

strbean wrote: post #86

Earlier quoted context omitted.

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.

To borrow a turn of phrase, the RDBMS is the best database technology going today, which is to say, it's the marginally acceptable one among the set of complete bagbiting loser database technologies that we have to work with out here in the real world.

Re: Why you should learn SQL

#133

Post by pjmlp » Thu, Aug 05, 2021, 5:27 AM UTC

laurent92 wrote: post #130

elmo2you wrote: post #93

Earlier quoted context omitted.

You are right, regarding the wastefulness. Additionally, there are extra risks involved when data needs to be transferred between a storage and compute facility. To a degree I get why architects these days like to separate everything into individual narrow and easier to manage/tuned services. But separating business logic from the data it runs on may equally be a fundamental mistake, when it comes to guarding integri…

The problem with SQL is integration with the rest of the code. I’ve already mentioned that Java not supporting multiline strings made it exceedingly hard to write SQL in-app and incentivized the use of frameworks; It is equally true that it is easier to deploy a .jar rather than a jar + stored procedures. To update a stored procedure, you have to execute SQL (as in, load a client, deal with exceptions, then actively…

I never had that problem, Java projects aren't a tiny Python script that only runs once.

Re: Why you should learn SQL

#134

Post by goto11 » Thu, Aug 05, 2021, 7:45 AM UTC

BiteCode_dev wrote: post #119

BulgarianIdiot wrote: post #91

Earlier quoted context omitted.

Databases have no "host" they have "clients" which are heterogenous. So directing this critique at SQL is completely unfounded. .NET added LINQ and now basic queries are integrated. It was not up to SQL, it was up to .NET And calling it "very low-level" makes me question if you understand what SQL does and is. It's probably the only mainstream 4th generation language I can think of. https://en.wikipedia.org/wiki/Four…

Host language, as in the language of your app that embeds some sql code, not host related to the db. The host language may or may not be the client language. It's low level because it lacks abstraction and anything outside the data query declarative paradigm is subpar. It has no notion of anything outside of itself, so it's a very restrictive inflexible dsl living in it's own bubble. And even worst, it lacks elegant…

I think you use "low level" in a different sense than is common. Low level (and high level) typically refer to abstraction level. SQL certainly have a very high abstraction level. But given it is a domain specific language it doesn't have much support for functionality outside of its intended domain (except through non-standard extensions). But a kitchen-sink language is not automatically higher level than a highly focused DSL - typically it is the other way around.

Re: Why you should learn SQL

#135

Post by DemocracyFTW » Thu, Aug 05, 2021, 9:49 AM UTC

eurasiantiger wrote: post #7

SQL is going to eventually die because of its three-pronged relationship model that implies query-time complexity. Learn it if you want, but especially backend and analytics people would be better off learning Gremlin or Cypher. Edit: downvoting this is not going to make it untrue.

I for one am in theory very interested in graph DBs, but in practice I yet have to see how do implement a solutions for my particular set of data (and my ideas about the data) in a graph DB without it becoming a huge ball of spaghetti.

If you're so enthusiastic about graph DBs that's good for you; as for me I enjoy having named rectangular sets of data (i.e. tables and views) consisting of smaller entities (columns / fields) that follow formally described rules (types, domains, check constraints, foreign keys and higher-order invariants). I do have a number of gripes about SQL but right now I feel quite happy about having achieved a reasonable way to integrate an RDBMS (SQLite) into my application environment (NodeJS) where I can fluently switch between formulating solutions in SQL or in JS with few restrictions.

Programming means you have to constantly keep a number of balls in the air, all the time. Having my data in handy tables is a big boon and not something I currently can expect a graph DB to do for me.

Re: Why you should learn SQL

#136

Post by KingOfCoders » Thu, Aug 05, 2021, 3:57 PM UTC

dominotw wrote: post #58

KingOfCoders wrote: post #21

We're currently moving our Druid/Kafka/Spark setup to BigQuery because of how simple SQL is.

My employer is going to the other way from snowflake -> druid to reduce high response latencies/ improve freshness. I am assuming your use cases can tolerate increased latency?

Yes they can, we will move low latency to a smaller, different pipeline.

Re: Why you should learn SQL

#137

Post by cratermoon » Thu, Aug 05, 2021, 7:02 PM UTC

BulgarianIdiot wrote: post #64

cratermoon wrote: post #23

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…

> half the products representing it adding some sort of SQL dialect support, which if you think about it is hilarious admission of defeat.

I don't see that as an admission of defeat. I see that as an attempt to provide some of the things that are good about SQL without dragging in the entire hairball of the language. Along the way, by choosing which subset of SQL to emulate the designers get to incorporate programming concepts that have come along since SQL. Things like user-defined ADTs, lambda expressions, and extensibility. Oh wait, LISP had all those before relational algebra was a gleam in the eyes of Date & Codd.