Fuuuuuck SQL.

If SQL is so great why does everyone keep trying to replace it!?!?!?!

/s

@IntrusionCM lets get him

@AleCx04

There,'s nothing to get.

Many NoSQL databases already have SQL / RDBMs features which get used by NoSQL dumbtards.

NoSQL was a no brainer.

Key Value Store would be the correct term imho.

And that's a useful thing.

Which - somehow unsurprisingly after longer thought - gets even implemented as a SSD (Key Value SSD).

Most people screaming "NoSQL great, SQL must die" will suffer the dreadful consequences.

Every time I got in contact with devs working on NoSQL projects or been contracted to govern / provide assistance / counsel NoSQL vs SQL it was the same:

- we don't understand SQL
- we want to shit everything into NoSQL
- it ended bad. We've got a clusterfuck.
- Help. It scales but our costs exploded and we lack severe manpower cause noone has a clue what's going on.

I think there were... Like 2 or 3 Projects where Elasticsearch / Redis were used correctly and governed in a sane way.

Every other project (I do not freelance - but when ever an old colleague asks for help and I like him, I'll help)… let it be 30 - 40... Was doomed to fail and ended in an shittogeddon. Shittogeddon means: You don't clean it. You'll burn it. Down to the ground. Plasma torch it.

Cause you need to start fresh, educate people, make sane workflows and whip everyone into shape. Luckily I could always go after giving recommendations.

:) so... Nothing to do here imho.

There’s like 30 commands in SQL and you only need like 4 of them... what’s the problem?

If data is relational use a bloody relational database. All the dialects are annoying but other than that SQL serves is well.

If your data is not relational or parts of it need to be very flexible (vary in fields/attributes/columns) nosql is awesome.

SQL really only sucks if you’re doing something that an ORM should be doing for you.

Yes yes, overhead. I understand and only barely agree. But if you are actually that worried about the performance hit, you are likely skilled enough that you can forego the help and write everything yourself, or you’re over-optimizing and will make your life hell.

Basic SQL? Easy-peasy.
Intermediate SQL? Still pretty easy.
Advanced SQL? Definitely some gotchas, and nested queries can absolutely be a pain.

@Root

Amen. Maybe that's some of SQL's magic. I'm no expert, my queries are usually dumb with some nested queries and such.

But I get along with it just fine, and maybe that's part of the magic, any idiot at a basic level can do the thing reliably, my coworker can see it and instantly know what it is doing ... and it's like the least crazy thing I deal with day to day.

The server in the background, hell if I know what is going on but it works every time...

If you can do a join, select, group by, order by, update, insert, and delete then you know enough SQL lol

Okay let's give you all a little bit more context. First, I know enough SQL (I took advanced dbms course). Second, I've been using nosql (mongodb) for long and it works like a charm. But why I resent SQL is because I use it with JavaScript/Typescript and it feels counterintuitive because everything in js is an object ( a key value pair). Also, SQL is hard to manage unlike nosql such as mongodb because there are enough cloud providers with good workflows. I tried using TypeORM and I absolutely hate their documentation. That being said, no one actually cares about sql anymore as can be seen in their documentations.

Again SQL in itself isn't a problem at all. Simple to use and intuitive but when used with JavaScript like languages where everything is JSON, it messes up everything. Hey, ever tried setting up docker for SQL?

Graphdb master race.

Golden hammer master race.

*Goes back to reading*

@ayushjn yes, both mysql and postgresql

@hjk101 yes and no.

The "freedom" to store varying data comes at a cost.

Let's not use the term NoSQL - let's use the correct term: Document Storage.

Varying data in a document storage system requires planning.

The higher the variety of your documents, most likely due to missing planning of mappings, the more trouble you'll get.

Higher variety of documenta "content" - higher bursts, performance drops, no fun.

The other part that most people ignore is that each document storage system has very different write models.

From inverted search indexes like Elasticsearch / Lucene to B-Tree / LSM like Wiretiger & MongoDb - each system hat it's owm behaviour and constraints.

Reason I dislike the word NoSQL and would avoid it: NoSQL is bullshit bingo.

That term should have died long ago.
It doesn't describe what you are talking about and even less what you mean.

@IntrusionCM actually I ment it both as key value and document store. It's often more performant when you store a blob of serialised data in a key value store.

All your points are beyond valid. NoSQL is a bs term. We can invent many No... terms (NoCompiler for instance).
I think it only can be used as a group term because SQL is so dominant (with good reasons, a lot of said NoSQL solutions now support SQL queries)

Was this NoSQL term born with frond-end app stuff? Than it probably is a misnomer for document store.
I always thought of it as relationaldb's vs the other solutions.

@hjk101 If I remember correctly from a bullshit bingo dev conference, NoSQL means "not only sql"

Looked it up...

https://en.m.wikipedia.org/wiki/...

Under History.

Was half correct...

Anyway... Pardon my venting, I'm just so fed up with these collective terms that make no sense whatsoever.

Life would be so much easier if humans wouldn't try to use abbreviations and collective terms in technical context.