5 ms·
This is a problem I've had to explain to too many developers recently. It's not faster just because you throw away data modeling practices and jam bits of info
by manyxcxi 10y ago
This is a problem I've had to explain to too many developers recently. It's not faster just because you throw away data modeling practices and jam bits of info all over the place.
If you have semi normalized data relationships, Mongo really doesn't fit the bill that well as your primary data store.
Where it shines is when you've got computed pieces of data to display (parts of a user data feed for example, data for a live graph, etc), you want to quickly store some data to be processed later (analytics, event processing), or you just use it as an object cache for expensive queries.
I have found that with a decently tuned DB, and I mean barely tuned, a decent data model, and sane fetching strategies (don't eager load everything always), a database can be good enough for quite a while, if not forever.
The answer I pretty much always get from people when I ask, "Why did you start with (whatever NoSQL they chose)?" Is, "Because (whoever) said it's faster and scales better."
I think younger devs that have options besides relational DBs find the barriers to entry on NoSQL lower (it looks mostly like how it went in and it's just JSON) so they pass over the learning SQL and basic data normalization fundamentals.
- jt2190 10y agoI agree with you, but would like to add that by using SQL to query a relational database it is very, very easy to denormalize the data that is copied into an application, so while a relational schema is essentially "static", query results are very dynamic, and can easily strip away all of the "goodness" that results from a normalized data structure. In other words, the application probably needs to deal with normalization and schema if it's taking copies of data, and using a relational database doesn't remove this requirement. (Of course, small applications often get away without enforcing schema, with the understanding that frequent database write failures due to malformed data are ok.)
- catnaroek 10y ago> find the barriers to entry on NoSQL lower Not having to think rigorously about the logical structure of your data is a huge selling point for many. For programmers, because it means they don't have to think. And for employers, because it means they can make do with programmers who don't want to think.
- 20years 10y agoThat is a scary thought.
- pbreit 10y agoOnly scary if you are locked into the past and/or closed-minded. (disclaimer: I'm not a mongo fan).
- 20years 10y agoI was mainly referring to "And for employers, because it means they can make do with programmers who don't want to think." Sorry, but I don't want to work in an environment where programmers don't want to think or don't have to think. That is a scary thought. Has nothing to do with being locked into the past or being closed-minded. Just the opposite actually.
- emp_zealoth 10y agoHow else do you think we arrived at webpages that need hundreds of MB of RAM?
- catnaroek 10y agoIt isn't that scary once you take into account the fact that our brains are just as finite as any other resource available to us. It's a virtue not to make more mental effort than what is strictly necessary to complete the task at hand.
- 20years 10y agoI agree with "It's a virtue not to make more mental effort than what is strictly necessary." but to have an environment with only "programmers who don't want to think" is not appealing at all to me. I personally want to be surrounding by thinkers.
- sangnoir 10y ago
- DashRattlesnake 10y ago> The answer I pretty much always get from people when I ask, "Why did you start with (whatever NoSQL they chose)?" Is, "Because (whoever) said it's faster and scales better." Pretty much the classic http://www.mongodb-is-web-scale.com/ http://www.mongodb-is-web-scale.com/?