Earlier quoted context omitted.
"I don't want to create a schema..." You are always going to end up creating a schema, whether it's explicit in your tables or implicit within your code. Otherwise you end up with completely heterogeneous data which is impossible to query in any useful way. This is a red herring.
Not really. Maybe some products have an attribute that others don't. Maybe you want to query by that attribute. The query won't turn up products without that attribute. Maybe that's ok. Like if you wanted to find all shoes with black laces you can just query for that. Tractors don't even have laces and so they don't come up in the results. In a sql db, every single thing needs to fit into a flat schema with nesting d…
The growing irrelevance of MongoDB
51–60 of 114 posts
Re: The growing irrelevance of MongoDB
#52I 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've used it and been happy. If you want something that's simple to use, know your schema partly but not entirely, and you don't mind losing a few writes, then mongo fits. Relational databases place such emphasis on reliability. Mongo is generally reliable but only two or three nines, and it's simple. For example, if you're collecting sub-cent line items for invoices, you might prefer to collect 99.x% of the line ite…
Re: The growing irrelevance of MongoDB
#53I 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…
> Facebook clone Diaspora is a social network that made the mistake of choosing mongodb for their first iteration. Here's a blog post where one of the involved developers explains why it's not good for that, even: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
Re: The growing irrelevance of MongoDB
#54Re: The growing irrelevance of MongoDB
#55Earlier quoted context omitted.
PostgreSQL has full support for JSON [1]. So, quite easily in fact. [1]: http://www.postgresql.org/docs/9.4/static/datatype-json.html
Thanks, I didn't know that. What's the benefit of using PostgreSQL though if the functionality is the same?
Re: The growing irrelevance of MongoDB
#56Earlier quoted context omitted.
PostgreSQL has full support for JSON [1]. So, quite easily in fact. [1]: http://www.postgresql.org/docs/9.4/static/datatype-json.html
Thanks, I didn't know that. What's the benefit of using PostgreSQL though if the functionality is the same?
Re: The growing irrelevance of MongoDB
#57I 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've used it and been happy. If you want something that's simple to use, know your schema partly but not entirely, and you don't mind losing a few writes, then mongo fits. Relational databases place such emphasis on reliability. Mongo is generally reliable but only two or three nines, and it's simple. For example, if you're collecting sub-cent line items for invoices, you might prefer to collect 99.x% of the line ite…
Re: The growing irrelevance of MongoDB
#58I 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…
> Can someone suggest when it is actually useful over a properly tuned relational database? In your own question you kind of hint at it. You need a tuned database. NoSQL lowers the barrier to entry for fast persistent data storage with replication. NoSQL doesn't replace SQL databases, it's looking to optimise a use case where transactions are not required. Personally I use Mongo a bit like a cache, sitting in front o…
I'd be curious to know in what contexts anyone would not want transactions.
I readily see the case for memcached or equivalent when it comes to caching -- it is very valid, and indeed useful, when slightly outdated data is perfectly acceptable. I can even picture how you might be using MongoDB to do the same, even if you admittedly have me wondering how you're invalidating the mess.
For a persistent data store, however, I'm honestly at a loss. In my own experience, transactions are needed as soon as there's a remote possibility that a concurrent write may occur. Even embedded systems need them, when you're threading statements concurrently for performance reasons, or when you're subsequently merging local data with another node. (See CoreData/iCloud bugs for what occurs when you ignore ACID in the latter case.)
Re: The growing irrelevance of MongoDB
#59Earlier quoted context omitted.
"I don't want to create a schema..." You are always going to end up creating a schema, whether it's explicit in your tables or implicit within your code. Otherwise you end up with completely heterogeneous data which is impossible to query in any useful way. This is a red herring.
Not really. Maybe some products have an attribute that others don't. Maybe you want to query by that attribute. The query won't turn up products without that attribute. Maybe that's ok. Like if you wanted to find all shoes with black laces you can just query for that. Tractors don't even have laces and so they don't come up in the results. In a sql db, every single thing needs to fit into a flat schema with nesting d…
Re: The growing irrelevance of MongoDB
#60I 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 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? Seamless auto-sharding, supported as a first-class use case. Particularly in a cloud environment where you can have your system automatically spin up more hosts as load increases (and take them down as load drops) with zero human intervention…
FoundationDB is a bit weird, but it handles automatic scaling-out, and has an ANSI SQL interface (backed onto a K-V store): https://foundationdb.com/key-value-store/white-papers/scalab...
Caveat: I've not used it for more than hobby stuff yet, but it's a fascinating bit of technology!