MongoDB et documents incorporés, bons exemples

Question

J'utilise des documents incorporés dans MongoDB pour une application Rails 3. J'aime pouvoir utiliser des documents incorporés et les valeurs sont toutes retournées avec une requête et il y a moins de charge sur le serveur de base de données. Mais que se passe-t-il si je veux que mes utilisateurs puissent mettre à jour les propriétés qui devraient vraiment être partagées entre les documents. Est-ce que ce type d'opération est faisable avec MongoDB ou est-ce que je ferais mieux d'utiliser des relations basées sur des id normales? Si les relations basées sur les ID sont la voie à suivre, cela affecterait-il grandement les performances?

Si vous avez besoin de connaître autre chose sur l'application ou les données, je serais heureux de vous faire savoir ce que je travaille avec.

Document possédant de nombreuses propriétés partagées par tous les documents.

Person 
name: string 
description: string 

document qui veut utiliser ces propriétés:

Post 
(references many people) 
body: string 

Answer 1

Tout cela dépend de ce que vous allez faire avec votre modèle de personne plus tard. Je connais au moins un exemple de travail (blog utilisant MongoDB) où son développeur conserve les données des utilisateurs dans les commentaires qu'ils font et utilise une collection pour l'ensemble du blog. Bon, d'accord, il utilise le second pour son "nuage de tags" :) Il n'a tout simplement pas besoin de garder une liste centralisée de tous les commentateurs, il s'en fout. Son blog contient des données consolidées de tous ses précédents sites/blogs ?, presque 6000 messages au total. Les messages contiennent des commentaires, les commentaires contiennent des utilisateurs, les utilisateurs ont des emails, il a l'option "abonnez-vous aux commentaires" pour chaque utilisateur qui commente un message, l'autorisation est gérée par l'agrégateur de service externe OpenID (Loginza), leur "jeton de connexion" dans leurs cookies. Donc, la fonctionnalité est plutôt bonne. Donc, la vraie question est: qu'allez-vous faire de vos utilisateurs plus tard? Si vous pensez vraiment avoir besoin d'une collection séparée (vous allez laisser les utilisateurs disposer de panneaux de contrôle centralisés, avoir un enregistrement basé sur le site, vous allez créer des fonctionnalités centrées sur l'utilisateur, etc.), rendez-les séparés. Si non - gardez les choses simples et amusez-vous :)

Answer 2

Cela dépend de ce que les informations utilisateur que vous souhaitez partager acrross documents. Disons si vous avez un utilisateur et un utilisateur ont des emails. Ne fait pas de détour pour déplacer les e-mails dans la collecte séparée, car il n'y aura pas plus de 10, 20, 100 e-mails par utilisateur. Mais si l'utilisateur dit avoir de grandes informations connexes qui ne cessent de croître, comme les billets de blog, alors faites-le pour le déplacer dans une collection séparée.

La réponse dépend donc de la structure du document utilisateur. Si vous montrez la structure de votre document utilisateur et ce que vous envisagez de mettre en collection séparée, je vous aiderai à prendre une décision.