In both cases, we had to sort of "back out" our original design, tweak the documents (usually creating new collections), etc.
How could we have avoided this? It didn't bite us too bad but it could have I guess. Obviously, I think the book is meant for people like me, but I wanted to get in a question and see if there's any good suggestions on how to plan out your "schema" and test it, but without actually doing it...Or maybe the best suggestion is to go ahead and use a few tracer bullets/spikes to actually see what is like to work with the data in that fashion.
Of course, many of these rules of thumb can't be satisfied all the time, and thus comes the 'art' of schema design in MongoDB. The best advice I can give is to try different approaches, turn on slow query logging and the profiler, make sure you have the right indexes defined, and be ready to adapt when you find a better way to do it.
Hope that helps!
Try to keep things that need to be updated atomically inside the same document, since making correctness guarantees across documents without real transactions is tedious and error-prone.
Ideally, have the 'unit of work' you're dealing with only touch a single document. In a web app, for example, this would mean that each page only loads a single document.
Those sound like great tips. We started with the mindset of 'put everything about a model/object in the same document' but invariably we split it out. Which has been just okay.
Anyway, thanks for the tips and Q&A this week, I look forward to reading the book.