Of course it's bad, and this holds true for any technology. Can you use it in any application? Probably yes, the question is how good the outcome will be and how much effort it will take.

Do you need transactions? Forget any NoSQL. To meet this people are re-creating transaction control in the application, probably much worse. Or they are "letting go", after all in most cases it works. It has applications that can work in most cases, there are applications that need to work in all cases.

Needrelationships?ItwillsufferwithanyNoSQL.AndI'llsayonething:mostapplicationsneedrelationships,andnottousethem,applicationsarecreatingredundantdataandworkingconsistencyintheapplication.Thiscanbegoodorbad.Theperformanceislikelytosuffer.

MongoDBhastransactionsonlywithinthedocument,andifIamnotoutdated,withlimitations.Isyourapplicationdocument-oriented?Mostarenot.

I'mnotgoingtotalkaboutNoSQLasacachebecausethisisnotthecasewithMongoDB,butcachingisaverydifficultproblemandgenerallyasolutionisaccepted.

That'swhyIalwayssaythatarelationaldatabaseshouldbethefirstchoice,untilitisnolongerappropriate.Eventodayrelationalistsprovidenon-relationalcharacteristicsthatintegratewellandhavethebestofbothworlds.

Generallyspeaking,what'sbestdependsontheusagepattern.

Myths

• NoSQLisbestforlargevolumesofdata

  Itmaybe...insomesituations.Butifyouneedtheresourcesmentionedabove,what'stheuseofbeingbetteratsomethingthatdoesnotprovidethenecessary?

• NoSQLhasbetterperformance

  Eachtypehassomeadvantageifitdoesaparticularoperation,butitisnotgoodatall.

  TherearecasesthatMongoDBwillbeveryfastforwritingandreading(youprobablywouldnotneeditwiththispattern).

  Writingisslowandhasnomiracle.Itispossibletominimizesomeeffects,especiallyamplification,butwillnotchangeabsurdlywithoutcompromisingdurability.

  Mostapplicationsdoalotmorereadingthanwritten.ButifthereadingsareisolatedMongoDBgoeswell,theproblemiswhenitstartsdoingdocumentrelations.

• NoSQLscaleswell

  It'strue.Ifyoudonotneedrelationshipsandtransactions.Climbingthesemechanismsisverycomplicatedinanymodeladopted.IfyouabandonthemtheeasySQL-basedscalemodel(atleastthegoodproducts).

TherelationalmodeladoptsACID,NoSQL(actuallythecorrectNoRel)adoptstheCAP.Youneedtoknowwhichoneismostimportant.IfyouneedACID,forgetNoSQL.

ThereisalreadyahybridmodelbasedonNoSQL.Icannottelliftheresultsaregood,butI'msuretherearedrawbacks.

ThereareseveralreportsofpastdramasbecausetheyadoptedtheMongoDBbyfadandnotbynecessity.EveryonethinksitisFacebookwhentheyareatmostanindustrywithcomplexprocessesthatcannotfailandlowvolumesofdataandoperations.Facebookhasneedsandadvantagesthatyoudonothave.

MongoDBcanbeusefulinsecondaryormajorapplicationswhenthecoreactivityisfocusedentirelyonunstructureddocuments.

Seemore:

• What are the most common types of databases for web applications?
• How to choose between NoSQL and SQL?
• NoSQL is as problematic as it sounds?
• What is a NoSQL database? How is it working?
• What makes a JOIN bad for a database?
• What does document-oriented?

NoSQL is best suited for those systems that have greater storage and performance needs. There are several types of NoSql bank, MongoDb is a document-oriented Nosql bank. This type of bank has an incredible performance for writing and not so good for reading.

In this project, posted in github, we can have a performance comparison against Mysql link

In other words, MongoDB is recommended for projects that require a lot of writing.

Another great advantage is the ease of staging the bank for multiple servers, perhaps this should be a bigger reason why many companies adopt this type of bank nowadays.

I really like the mongoDb, I'm more accustomed to it. It is very fast, it is also the most used nosql database in the world, with a very large community. In mongo you work with collections and documents, since it is not SQL you use Bson's language that is based on Json.

It is important to note that a NoSQL database is very good, but it does not eliminate relational Dbs in SGDB, after all, decades of proven experience should not be excluded. In some cases it will be better one than the other, but there are cases, like mine where I use the two types of databases in a hybrid way.

This guy's blog link is cool to understand some very important things about mongoDb and helps you understand some care about MongoDb fairly evenly. More things can be seen here link

Because mongoDb allows you to insert fields anywhere in your document, this is possesses schema-free, so care should be taken to create your data architecture because of this flexibility.

A legal case to use Mongo is in a dynamic form where the user can create random fields depending on his need when we do not know which fields will be created so he can be created in the document according to the need.

I hope I have helped. Falow!

My response is based on hands-on experience.

Mongo stores JSON. If your application is handling many JS objects and you want to persist these objects, use MongoDB. This will make your DAL and MVC layers very thin because they are not wrapping all the properties of the JS object and trying to force them into a structure (schema) in which they do not fit naturally.

Writing speed?!?!
It is not using MongoDB that you will have this advantage, if you really need to solve a problem of writing speed of your data use another bank type Voldemort.

Scheduling?!?!
Who needs this in practice ?! Facebook?! Unless you're creating something to compete with Facebook, why would you need to stagger !? :)

If you want to use MongoDB blz, but do not expect it to do magic for you.