Sure, if you want SQL or traditional relational database, a traditional relational SQL database is a better choice. Using Postgres or Oracle for workloads better suited to tied hashes or BerkleyDB doesn't automatically become "right" though.
The growing irrelevance of MongoDB
11–20 of 114 posts
Re: The growing irrelevance of MongoDB
#12I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…
I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well.
Edit: Sorry for my short and unprecise comment. I regret posting it, loosing all my Karma. Yes, of course I would use a schema, but I may use hundreds to get my products presented with all attributes and variants available. There is a set of attributes that will remain for all products, others will vary, some will change and will be dropped. Some may be conditional, depending on size or color. I could model that in RDBMS as well, adding those properties in an additional JSON or something else.
Yes, I'm also mainly using relational databases and just wanted to give an example of a use-case for MongoDB. I regret, sorry.
Re: The growing irrelevance of MongoDB
#13Basically I got out of it:
- he likes JS, and was comfortable with MEAN-stack (MongoDB/Express web framework/AngularJS/Node.js)
- he found that for document oriented purposes MongoDB could sometimes be a nice fit
- he found that replacing MongoDB with the drop-in replacement TokuMx (seems like a MySQL/MariaDB type of idea), he could get a big performance increase
- he found that with Postgres 9.2+ using the JSON/document storage there he could get some of the relational benefits and some of the document benefits, and ACID
- he likes ACID because of transactions/handling multiple documents at once
Ok, so I guess I was wrong, there is a bit there. But: this is all stuff that I've heard several times about MongoDB.
One of the things he got into was that he learned when MongoDB was appropriate and when it wasn't -- but IMO he didn't really go into detail here other than to say: joins and transactions. I wish there was more substance than that.
I also seem to recall reading recently that even supposedly ACID compliant databases have problems with transactions under load and that the only way to really get full ACID compliance is to treat transactions as serializable - perhaps I am wrong but I think this is the gist of what I've learned.
Personally, I'm working on a project right now that uses MongoDB and I definitely do miss joins, transactions, and schemas. I am not even remotely sure where one would benefit from a system that had documents with arbitrary fields in it. (I didn't pick the technologies for my project.)
I would really like to know when to choose which database - I feel like I know the bare basics of several, and none of them in depth. I really don't have time to learn them all. I feel like even when I'm building one application it's only some months after deployment that if I'm lucky or made a mistake that I will run into some actual performance constraint.
Re: The growing irrelevance of MongoDB
#14I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…
Maybe I'm getting old, but I really want DB to just work (unlike HBase, at least a few years ago). Other than that, I'm flexible.
Re: The growing irrelevance of MongoDB
#15I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…
Think of an Amazon like product catalogue. I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well. Edit: Sorry for my short and unprecise comment. I regret posting it, loosing all my Karma. Yes, of course I would use a schema, but I may use hundreds to get my products presented with all attributes and variants available. There is a set of attributes that will remain…
Re: The growing irrelevance of MongoDB
#16I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…
Think of an Amazon like product catalogue. I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well. Edit: Sorry for my short and unprecise comment. I regret posting it, loosing all my Karma. Yes, of course I would use a schema, but I may use hundreds to get my products presented with all attributes and variants available. There is a set of attributes that will remain…
Re: The growing irrelevance of MongoDB
#17I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…
Think of an Amazon like product catalogue. I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well. Edit: Sorry for my short and unprecise comment. I regret posting it, loosing all my Karma. Yes, of course I would use a schema, but I may use hundreds to get my products presented with all attributes and variants available. There is a set of attributes that will remain…
Re: The growing irrelevance of MongoDB
#18I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…
Re: The growing irrelevance of MongoDB
#19I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…
Lately (and not so lately ;) there has been a lot of bad press about MongoDB. We use it extensively as part of our product (on single servers) and it fills this role nicely. It has a few drawbacks, most notably huge disk space requirements (MongoDB has no compression) which we are hoping to solve with TokuMX (haven't tried it yet). It has some other quirks too, but in general it just... works. And I love using a docu…
Re: The growing irrelevance of MongoDB
#20I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…
Think of an Amazon like product catalogue. I don't want to create a schema in a relational database for that kind of use case. A MongoDB fits as well. Edit: Sorry for my short and unprecise comment. I regret posting it, loosing all my Karma. Yes, of course I would use a schema, but I may use hundreds to get my products presented with all attributes and variants available. There is a set of attributes that will remain…