Which one do you prefer between Relational and NoSQL databases?
- How do you decide which one to use in your job?
- Which use cases have you identified on when using a certain kind of database?
Let us know what you think and use in your job!
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (8)
Generous SQL (or NoSQL) hosting similar to MongoDB Atlas?
Pacharapol Withayasakpunt ・ May 29 ・ 1 min read
You are not correct when you say “RDBMS is generally more performant“.
Nobody asked about ORM or ODM. You confused the guy. A database is not programming language specific.
“you would probably want to avoid relationships in NoSQL” there are NO relations in NoSQL.
JOIN is a feature of an SQL database which make it slow in performance. In more cases, NoSQL is more performant when you compare it to an SQL DB with JOINs. But this is very abstract. It is case specific. And we should not compare performance of these 2 since they are used in different scenarios.
Lastly, we should say that NoSQL is a collection of multiple different databases which are not SQL. It could be document-oriented like MongoDB, it could be key-value like Redis, graph DBs, etc... we should not compare what is faster, we should only compare specific cases since each of them was built for a different purpose.
A database isn't programming-language specific, but everything else from drivers, to programming, to maintenance, are.
Otherwise, I could be wrong. I have little experience with NoSQL. NoSQL is the path less people take, and I am just advised against taking...
Also, IMO again, relationships can be anywhere, only just managed directly by the database or not.
I personally equate NoSQL to newer databases, created anew from scratch, rather than relying on SQL structure; and tried to solve problems (which can actually be unsuccessful, but marketeers won't let you know, if possible). So I do know there are multiple types. And NoSQL can also be ACID-guaranteed.
Not that the old technology, SQL, aren't getting updated. It is just not remade from scratch, that's all.
IMO, it is more of relying on cutting edge technology, or a stable technology. Again, "being made for the purpose" can fail. Only what can make sure for me are either, successful cases, or tech / liability support.
I totally agree with the statement that SQL is older and there was no improvement for a longer time.
If we look at MongoDB, they released support for multi-document transactions in 2018. So the debate of using MongoDB vs an SQL DB specifically could be a nice topic to discuss. But still, we should focus on use cases and not performance comparison.
MongoDB specifically, vs SQL (mentioned PostGRES) are discussed here.
PostgreSQL vs MongoDB
Ben Halpern ・ May 28 ・ 1 min read
Personally, I see MongoDB transactions as not yet in place, and lacking named SAVEPOINTs. And sometimes that matters a lot.
Thanks for that. I will read it ;)
This question is always answered by the type of data you're looking to store. In practice, we start at the end of "RDBM-first", and as the data we're storing gets flatter, the more likely we are to move closer to recommending a nosql solution.
As mentioned above: flat, infrequently-mutated data is a perfect use case for nosql.
Why?
The main draw of nosql systems is performance. Single-row table performance of nosql systems is almost always unbeatable by nosql platforms. This is because it has stripped out most of the overhead of indexing and relation management of traditional Sql-backed systems.
This matter to us because it means we often cannot rely on the data store to help us keep our data in good shape. All of that functionality needs to be handled by our application instead. This means more code by us, but it also means that data retrieval is wicked-fast.
The flatter the data, the less each row relies on data from another, which means we don't need to care about relations. The less we need to update specific rows, the less we need to rely on our application to run prechecks to make sure we're not breaking anything or corrupting our data.
You may find this talk interesting - discussing different DB architectures and use cases for each of them!