loading...

re: MongoDB has no use case VIEW POST

FULL DISCUSSION
 

The biggest turn off, for me, is the simple concept that MongoDB/ObjectDBs enforce the concept of persisting OPINIONATED data structures. The concept of relationships do not inherently exist within the db realm; they must be enforced by an external program (correct me if this has changed, or is down-right wrong).

Yes; I support the notion that document databases are useful during prototyping. They are also, arguably, useful for caching data served from a JSON-powered integration; if the data is only refreshed daily, there's no need to call the API endpoints on each request (just cache it, as is!).

With that said, if your data outgrows the confines of a simple transaction-layer CRUD application, and into the realm of data analytics, you will be spending more time destructuring your objects, and restructuring them into either normalized data sets, or into the structures that you require for said task. This is essentially a form of technical debt, if you're coming from RDMS.. The data, what would have been stored in normalized, and enforced, separate entities are now grouped together into an opinion that, was the opinion of the application that collected the data, but no longer the opinion needed.

As far as the fallacy that MongoDB is 'faster' than SQL supporting RDMS, there's plenty of data on the net, and at your library/uni to support the contra. Just my ignorant 2 cents..

 

if your data outgrows the confines of a simple transaction-layer CRUD application, and into the realm of data analytics, you will be spending more time destructuring your objects, and restructuring them into either normalized data sets, or into the structures that you require for said task

This remains the single biggest reason I still haven't made the mental switch. Or let's say, this is the only reason standing in the way. I think all other features are most welcome, but having to wrangle with data again and again ... no, no! Maybe it makes sense to use MongoDB as an analytics cache that is constantly being updated.

As far as the fallacy that MongoDB is 'faster' than SQL supporting RDMS, there's plenty of data on the net, and at your library/uni to support the contra

Yup. The biggest bottleneck is the network, at least as far as I think. Whether a DB read takes 20 nanoseconds or 200 milliseconds doesn't make a tangible difference. 🤔

 

having 20ns response is highly desired in map reduce jobs, which are often computed in the mongodb server itself.
Also Now that mongodb supports joins using lookup,
lookups can be efficient with faster read operations,isnt it?

code of conduct - report abuse