81–90 of 114 posts
If transactions are the biggest problems, there are driver solutions like http://godoc.org/labix.org/v2/mgo/txn for that. I am not sure, how they compare to "real" transactions. Still missing "joining" in some cases though. Otherwise I am ok with MongoDB so far.
If another host connects to the db, and the transaction doesn't span to that second host. Its not as safe as sql transactions.
Earlier quoted context omitted.
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…
In a sql db, every single thing needs to fit into a flat schema with nesting done by relations. Nope, see Postgres (hstore and json).
Earlier quoted context omitted.
In a sql db, every single thing needs to fit into a flat schema with nesting done by relations. Nope, see Postgres (hstore and json).
why not "see sql server from 10 years ago with xml column type"?
Earlier quoted context omitted.
Not at all. Let me run an example with simple and made-up numbers. Consider two storage solutions used to gather line items to invoices. The line items are ten cents on average. One system is properly ACID, and running it costs one cent per line item on the invoice. The other loses 1% of writes randomly, but its hardware/backup/ops requirements are lower, so it costs just 0.1c/item. The ACID way gives you complete in…
So, if I want to incorrectly invoice my customers then I should use MongoDB? I don't understand how you can say any of this seriously.
Overinvoicing would be bad. But underinvoicing is just another cost of business. If the cost is smaller than the alternative, fine.
If transactions are the biggest problems, there are driver solutions like http://godoc.org/labix.org/v2/mgo/txn for that. I am not sure, how they compare to "real" transactions. Still missing "joining" in some cases though. Otherwise I am ok with MongoDB so far.
http://blog.labix.org/2012/08/22/multi-doc-transactions-for-...
While it does work, it's still a workaround for the lack of first-class transactions in MongoDB. It offers a more limited API and requires care on the developer side.
Despite being the author, I do hope it gets obsoleted by more convenient first-class transaction support in MongoDB itself at some point in the near future.
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…
We are building a music streaming website. Think of it as a Spotify for Pakistan and Mongo has been wonderful for the kind of Data Structure we have. Its perfect for a catalogue like structure where objects can very easily nest inside each other. Each Artist has multiple albums, and multiple artists have multiple songs. All of this nestles very neatly inside eachother, and when i want a song, i almost always need its…
The general consensus on the use case for something like MongoDB is actually the opposite of what you opine. It works well for large, loosely defined datasets where many fields can be optional or empty, for example something like patient medical data, with few or very basic relations between objects.
I don't think that anyone besides the "evangelists"(shills selling snake oil) would tell you to use something like Mongo if you have a well-defined and predictable dataset.
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…
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…
If you say so.
Earlier quoted context omitted.
> 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…
> 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. 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…
I personally like MongoDB for: - flexible schema (less migration pain) - easy tags implementation - product attributes (list of name-value pairs) - GridFS - store binary files - nested documents for analytics (ex: a record for each day with a nested doc for each hour)
I wish MongoDB had - some support of join - multi-master replication
I personally used MongoDB as primary storage (yeay dot me), but currently prefer it as secondary storage.
As any product it evolves and I expect to see more improvements. I think MongoDB brought NoSQL to the masses :)
Just my 0.02. Thanks.