So the thing I've heard is that, it turns out, for 99% of use-cases you don't need any form of NoSQL, and a standard-ass RDBMS like MySQL or Postgres is fine. And if you DO need unstructured data, Postgres has a JSON/JSONb data-type with syntax built into the SQL syntax for querying it.
So, what are some legitimate use-cases for NoSQL databases, and which ones, for the average developer who doesn't have insanely unique requirements, are actually worth a damn?
I've been out of the loop for a while because I've just been using Postgres, but RethinkDB and ArangoDB stand-out to me as DBs actually kinda being worth something.
... so, NoSQL thread. Feel free to shitpost and jump on the NoSQL-hate bandwagon without understanding anything.
I use NoSQL for toy projects when I know I'm going to write hack after hack and modifying my schema after every iteration would be a pain in the ass.
This is probably the only good and legitimate NoSQL use case.
>>54978820
mongodb is great for prototyping, dotn have to predefine fields.
Also, I like the Idea of self containing documents. Why not put all information into one document instead of joining multiple tables to get it.
>>54978883
I've never heard of anyone prototype in something like Mongo and then going on to do it in SQL.
And yes, the lack of predefined structure is the common bullet point for considering them. But I think if you design your tables sanely in SQL DBs, you can pretty much get anything done, and the benefits of ACID and great queryability on top of it.
I've also heard that, ironically, using PostgreSQL with JSON fields is actually more performant than MongoDB. So there's that.
Berkeley DB is nice
Mongo is absolute crap though
>>54979956
BerkDB and its brethren are key-value stores, and an embedded one at that. Not to mention that there's no network protocol for it, so it can only be accessed locally.
It can't really be grouped with "NoSQL" at all, as nice or as useful as it is.
Just got for a standard SQL base and use an ORM if you want object-oriented memery
no need for this unstable, untested bullshit at least until it's stable and tested
>>54980249
Wise anon is wise.
>Stable and tested bullshit is better than untested and unstable bullshit
>>54978820
It really depends on the task, where I work we usually go with NoSQL whenever we have to query large amounts of data and when it has to be done fast.
>>54980022
NoSQL simply means it is a non-relational database
It's not a new concept either, in fact it's older than SQL, even if the meme buzzword is new-ish
>>54980249
There's lots of (decades) old stuff that is good if you make an informed choice instead of jumping onto the latest hype bandwagon. Sadly, web devs seldom understand anything so they can't do much but follow the newest trends blindly.
Also MongoDB is absolute crap. That doesn't mean something legit like Berkeley DB is crap though.
>>54978820
Redis is the only one of those I've used. It's a bit different to the others because it's in-memory rather than on disk
I used it with Rails and Sidekiq. Sidekiq is a gem that does background / asynchronous processing (i.e. processing outside of request/response cycle).
So basically you queue up a job in Rails, it gets added into Redis, then Sidekiq (which is running in the background) picks it up and executes the job. So basically this just avoids the user having to wait for the Rails process itself to execute the job, whatever job it is.
I think Redis is designed to be super quick for just this sort of case so it seems like a good use for it. Would surely be unnecessarily slower to store jobs in a MySQL table or something, since the job will only exist for a few seconds (obviously it depends how many jobs you're executing and how long they take)
>>54980726
>NoSQL simply means it is a non-relational database
Not really, RethinkDB for example is a NoSQL DB that supports a subset of the relationships features you'd expect from a SQL DB. Not proper foreign keys and automatic ON DELETE behavior for example but all sort of joins and other queries based on relations.
