When it comes time to pick the database you'd like to use for the back-end of your particular application you have two choices for the type you'd l...
For further actions, you may consider blocking this person and/or reporting abuse
Nosql has transformed and disrupted how web pages are presented. It's more suitable for web apps and has been fully adopted by major IT players such as Google.
Sql with its stability and power, begins to run into challenges with super large databases.
Large queries don't just die, they just take 8 hours or more to return
data. Join operations can be highly expensive.
I worked for a major healthcare institution who suffered immensely from their massive SQL solution. A Google exec on their board, steered them to Nosql where they began implementing huge data migration projects.
Reason: Doctors and nurses wanted web apps for immediate patient feedback. Sql was too slow.
With cache you can make web apps respond faster, not only by using NoSQL solutions.
For anyone wanting to combine the two approaches I strongly recommend Postgres. It has excellent support for JSON columns, which overcomes some of the listed limitations of NoSQL databases, but also allows you to store "unstructured" data.
I'll have to look into it for sure, I'm by no means an expert in this- 4 weeks ago I didn't even know what a SQL database was! I believe mySQL lets you store JSON now as well but I'm not sure how efficient it is at it.
And yeah, unstructured might not be the best word, maybe unorganized? That also seems a tad off though since JSONs are pretty structured/organized as well.
This is true:
And also this:
plus the cost of duplication of data.
Your article reminds me of Sarah Mei's Why You Should Never Use MongoDB
She explains with more detail why MongoDB(I take it for many NoSQL) is not ideal once your app starts having relationships on its data. Which probably will always happen in any application.
The use case for NoSQL storages is for unorganized data but I think that specific use case firs better for features of a webapp rather than an app itself.
I don't think my post can hold up against Mei's article but I'm flattered it reminded you of it!
Honestly, based on my limited experience with both databases, I'd use MongoDB all the time if I could. If only because it's so much easier to pick up and understand than having to query and join tables. Raw mySQL queries can get really lengthy.
Sadly, the more complex my apps get as I learn I'm going to have to bite the bullet and embrace relational databases sooner or later.
Just to be clear, document-oriented databases are not the same as NoSQL databases. Document-oriented databases are a subtype of NoSQL databases. Other such subtypes are Graph databases, Key-value pairs, wide-column databases. All of them have their own specifications and unique things. The advantages of flexibility you mentioned are applicable to document-oriented databases and all NoSQL ones. So, it means that after choosing between SQL and NoSQL DBs, in case you decided NoSQL, you still have to select the subtype you want to use. Of course, document-oriented DBs are the most popular now, however, the others also have the use cases where they shine and outperform the document-oriented DBs.