41–50 of 114 posts
Earlier quoted context omitted.
So what happens when you want to list all of the products in a category?
query = db.products.find({'type': 'Film', 'details.actor': 'Keanu Reeves'}) @see: http://docs.mongodb.org/ecosystem/use-cases/product-catalog/ I personally miss Joins in MongoDB - but other vendors support Joins.
I 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…
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...
I 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…
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 items simply over 100% at greater complication and expense, particularly if you can measure x.
I 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 been building https://rwt.to and https://movingjoburg.co.za with storage backed by MongoDB. Both are transit apps/websites in South Africa, could be more useful, except that we spend most of our time collecting and capturing data.
At the time I was very inexperienced (I guess I'm a bit better now?), but these are the reasons why I chose MongoDB.
1. Geospatial query support out of the box (this is during 2.0-2.2). It's now great with GeoJSON, I store routes and stations as GeoJSON, and querying them is very easy. Compare with PostgreSQL + PostGIS.
2. Some bus services have weird schedule structures, and I needed to be able to generate those schedules, I store schedules as a giant JSON file, and I can query that file to find when the next bus/train is. It's now possible with JSONB in PostgreSQL, but trying to fit that into a relational model wasn't worth the pain at the time, especially when there's always edge cases that I have to cater for at times.
3. To create a pricing engine on rwt.to, I needed a very flexible schema, because I have to cater for many cases (are there bus/train transfers, discounts, and quite different rules for those transfers and discounts). MongoDB gave me the ability to vary my schema in the instances where I needed to store different types of data. I'd rather contend with that than have a table with 100 columns to do the same. To head off on a tangent, in GTFS this data (fares) is computed and stored in the table, but I calculate fares at query-time because there's sometimes a lot of rules to consider, making calculating them and caching them like GTFS unpleasant.
4. Other reasons was because it was pleasant to work with MongoDB + Mongoose.js. This is very important as I'm the sole developer, and due to my line of work, I don't get all the time I need to work on both projects. For my core transit data, I won't reach >20GB even when I manage to collect all the data for South Africa, so I won't have to contend with the 'big data' issues that other users would face.
PS: Out of interest, if anyone would like to try rwt.to to see how it works, here are some example links: - https://rwt.to/*mrwF8w0u - https://rwt.to/*mrCLEZaE - https://rwt.to/*mrOkEDKH
I 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…
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, which is really nice.
There are plenty of alternatives in that space nowadays (more than when mongo first came out), and reasonable people can disagree over whether to use mongo rather than e.g. cassandra, riak, or shonky third-party clustering addons for mysql/postgresql, but I've yet to see an affordable relational database with out-of-the-box auto-sharding support that comes anywhere close to what mongo offers.
(Also, first-class support for async-io clients. This is about client libraries rather than the server itself, and purely an artefact of when mongo was released, but if you're calling e.g. PostgreSQL from the JVM, most of the libraries are oriented towards blocking JDBC which is "good enough" (there are valiant efforts like https://github.com/mauricio/postgresql-async but you can't use them with established higher-level libraries). Whereas every mongo library offers a callback- or future-based API, and the higher-level libraries are built around this)
Earlier quoted context omitted.
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…
"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.
In a sql db, every single thing needs to fit into a flat schema with nesting done by relations. Additionally, it's very rigid. Maybe you just don't want to set up a laces table, and 4000 other tables for every little attribute of every product. Of course this is not how you would do it in real life, there are better ways. Mongo is one of those ways.
Saying that Mongo is good for nothing is just as dumb as saying that Mongo is good for everything. In 2015, the Mongo backlash is just as tired as the Mongo hype.
Earlier quoted context omitted.
query = db.products.find({'type': 'Film', 'details.actor': 'Keanu Reeves'}) @see: http://docs.mongodb.org/ecosystem/use-cases/product-catalog/ I personally miss Joins in MongoDB - but other vendors support Joins.
There - you're consistently using a field named "type" across your objects - you're using a schema.
Earlier quoted context omitted.
I just like being able to insert a random JSON into a collection and query it by any of its properties. Not sure how I would do that with a relational database.
PostgreSQL has full support for JSON [1]. So, quite easily in fact. [1]: http://www.postgresql.org/docs/9.4/static/datatype-json.html
Earlier quoted context omitted.
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…
>And I would appreciate a way to define schema Use mongoose! >On the other hand, I do miss JOINs when I need them (though we solved that on app level). How you do that? (maybe is different than me) What about transactions?
We don't use node.js. Also, we have app-level schema, but enforcing should (IMHO) be done on DB level so as to avoid any chance of invalid data.
Joins: easy, we specify which fields are connected (on app level), then fetching goes to connected collections and fetches data from there too. Not ideal, but it works. We made a similar solution for foreign keys.
Transactions: no need for any further guarantees. Our system mostly works on a single record at a time in all critical components. If this is not possible, we have app-level locking to avoid conflicts. No issues or wishes here.