12
votes

COUCHDB Créer une base de données par type de document?

Je viens de commencer à jouer avec Couchdb et j'aime vraiment ça jusqu'à présent, mais je me demandais quand vous devriez créer une nouvelle base de données.

Voici ce que je veux dire:

Si je devais créer un blog sur un serveur avec multiples blogs et c'était un SGBDM, je créerais une base de données appelée fox_blog et créer des tables et des relations pour les messages, les commentaires, etc. .

Maintenant à Couchdb, je ferais simplement 3 types de documents: messages, commentaires et comptes d'utilisateurs.

Mais c'est ma question: Est-ce que je faisais un dB appelé fox_blog et ajouter un champ "Type" à chacun des documents (par exemple, dans les documents des messages, il y aurait un champ "Type" avec la valeur "Post ' )? Ou feriez-vous créer une DB distincte pour chaque document et précéder le nom avec Fox_ (par exemple, le nom de DB serait Fox_posts pour les messages)? Ou ne sont pas de ces corrects?

Faites-moi savoir si l'une de celles-ci n'est pas claire, c'était un peu difficile d'expliquer heh


0 commentaires

3 Réponses :


9
votes

Vous devez créer une seule base de données avec un champ de type dans chaque document.

Vous voudrez peut-être écrire une vue qui renvoie le document et tous ses commentaires ensemble.


0 commentaires

7
votes

Généralement, j'essaie de conserver des applications séparées dans chacune de leur propre base de données. Dans ce cas, si tous les blogs variables sont accessibles dans une seule interface, conservez-le dans 1 base de données, à l'aide de champs tels que type et blog pour identifier chaque document.

Si vous exécutez plusieurs blogs, accessibles à leur propre domaine ou à leur adresse, vous pouvez envisager de segmenter chacun des blogs dans leur propre base de données. Fondamentalement, CouchDB vous permet de faire une grande flexibilité ici, alors profitez-en de cela et d'expérimenter.


3 commentaires

La seule chose qui m'empêche de faire cela, c'est comment le canapé met à jour sa vue chaque fois qu'il y a une mise à jour. Alors prenez les commentaires par exemple. Ils sont mis à jour beaucoup plus souvent qu'une entrée de blog ne serait donc pas préférable de séparer les commentaires des messages dans certains cas (en supposant que je n'ai pas de vue qui combine les postes et les commentaires pour une raison quelconque )?


Bonne discussion. Fox, vous avez raison qu'il y ait plus de mises à jour, mais COUCHDB traitera (map / réduction) chaque document une fois chacun, fondamentalement après sa stockage. Si ceux-ci sont répartis dans plusieurs DBS ou stockés dans un seul, il sera à peu près la même chose. Je suis d'accord avec Dominic, règle de base: conservez-la dans une base de données lors de la sortie.


Très bien, je garde tous mes champs dans un DB pour l'instant et ça a l'air plutôt bien. Mais de ma compréhension maintenant, si je trouve un certain type de document n'est pas utilisé dans des vues qui incluent les autres documents, cela pourrait être une bonne idée de la déplacer à sa propre dB. Est-ce que cet état d'esprit est correct?



5
votes

Plus important encore de faire des requêtes sur plusieurs DBS n'est pas prise en charge directement - bien qu'il existe des voies autour de cela.

Dans votre cas avec des messages, des commentaires et des images dans des DBS séparés ne fonctionneraient pas du tout.

Vous pouvez utiliser la typing de canard ou l'utilisation d'un champ de type "Post / Commentaire", etc.

Couchdb possède une base de données utilisateur intégrée accessible dans votre application.


0 commentaires