Ultimately, two projects later I'm just not happy with Mongo as a data store. I've found that the restrictions of a relational data model mean that you don't end up paralysed worrying about how to store your data. In Mongo I was forever tossing up between embedding data or splitting it up into a separate collection. And it's a choice that may well bite you later. Also, only ensuring the integrity of your data within the application is not a great idea.
Regarding collections and embeddeded documents: Yes, a lot of times it makes sense to split things out into separate collections instead of embedding them so you don't run into problems later. One nice thing about MongoEngine and MongoMallard is that they update only fields that have changed. So if you have a ListField(EmbeddedDocumentField()) and change one of the embedded documents, only that document gets sent in the update statement, which speeds things up. And yes, I wish MongoDB had better ways to ensure data integrity.
Also since the site doesn't have comments include a link to this page in the end?
We're using our fork of https://github.com/elasticsales/flask-mongoengine/ (which I admit is based on a flask-mongoengine version that is a little bit outdated).
Also, will add a link to the comments.
That comes at some cost in MongoDB and document databases in general. Often it is best to start with the opposite of modelling a relational db - start denormalised and normalise where it makes sense to.
The catch with MongoEngine is know that ReferenceFields are dereferenced in the application layer and design your Documents accordingly.
And one of the selling points of NoSQL "document store"-style solutions is that, as they do not use the relational model, your data layout can more closely follow object construction and not need the kind of object-(datastore)-mapping represented by ORM, anyway.
