That was a dealbreaker for me. If MongoDB has now grown support for transactions, that changes things. I think I am going to look at it again sometime.
EDIT: Typo
If you have a “one-to-many(some)” kind of relationship, embedding is a good option, and gets you ACID semantics without even resorting to multi-statement transactions.
If you have a “one-to-many(thousands or more)” kind of relationship, objectID references (a la foreign key) is more likely what you want.
As far as I understand it, MongoDB's claim to fame is a) handling huge amounts of data and b) clustering. Neither of these apply to me, so the only reason to use Mongo would be data that does not match the relational model well. I am still looking for a use case, any use case, that might make a valid excuse to learn it, but so far I have come up empty.
I am a little worried that I am facing a situation somewhat like the one when I tried to learn Lisp. Learning Lisp was very hard for me because I had absorbed the structured programming approach so deeply that the functional part of Lisp programming seemed downright alien to me. At first, at least. So for the time being, I cannot tell with any certainty if problems that are a good match for a document store are just so rare, or if I am just incapable of modeling my data in ways other than the relational model.
A decent example is a person record with their email addresses and phones. In a relational DB, you would always and only model those as three sepearate tables, and you would quite frequently need a three way join to assemble that person again.
In MongoDB, you would definitely have an array of emails and an array of phone numbers embedded in that person document, sparing the join on those queries. But in an ecommerce context, you would likely not embed an array of all past orders with all the line items into that person, instead you’d have an array of previous order numbers.
But an order document would have an embedded array of line items, sparing the DB a bunch more joins (and the attendant indices you’d need for joining line items to orders efficiently).
Getting the 10 most recent orders from a customer would involve joining the customers collection with the orders collection (MongoDB’s join is the `$lookup` aggregation stage), but it wouldn’t involve joining the line items to the order.
Is that replicating a relational structure? A little column A, a little column B.