En fait, la philosophie de conception sur le site officiel est plutôt bonne (http://www.mongodb.org/display/DOCS/S...)
La plus grande différence entre MongoDB et la conception de schéma SQL traditionnelle réside dans la meilleure méthode pour exprimer les relations de modèle (dans MongoDB, vous pouvez utiliser Link ou Embedded)

Un bref résumé :

1. FirstClass (comme "User") doit utiliser une collection indépendante
2. Le "type d'entrée" doit être intégré
3. S'il existe une relation d'inclusion entre deux modèles, utilisez l'intégré
4. Pour les relations plusieurs-à-plusieurs, utilisez le lien (similaire à la clé étrangère en SQL)
5. Si un modèle peut stocker très peu d'objets, utilisez une collection indépendante, ce qui aidera le cache du serveur mongodb
6. La méthode embarquée n'est pas propice aux associations complexes et aux requêtes complexes
7. La méthode intégrée présente de grands avantages en termes de performances. Si vous avez des exigences de « performances », vous pouvez envisager d'utiliser l'intégration
.

Je suis toujours habitué à traiter mongodb comme une base de données ordinaire, à traiter les collections comme des tables, et la structure des données de chaque collection reste cohérente.
Je ne sais pas si c’est raisonnable, mais au moins cela clarifie ma réflexion.

NoSQL a une philosophie de conception unique et il est recommandé de ne pas se laisser influencer par la pensée RDB.
Je recommande également la lecture d'un article :
Schéma de mappage d'enregistrements MongoDB extrêmement gratuit Entité Java