2009-11-04 8 views
3

Il semble que vous ne puissiez pas imbriquer des bases de données dans CouchDB. Comment les gens travaillent-ils autour de cette limitation? Par exemple, supposons que je souhaite créer un moteur de blogging dans lequel chaque domaine possède une base de données distincte. Dans chaque base de données, je souhaite qu'une base de données Utilisateurs, une base de données Orders, etc. contiennent les différents documents utilisateur, les documents de commande, etc.Bases de données imbriquées dans CouchDB

La façon évidente semble être une structure plate où le nom de la base de données délimite la frontière artificielle entre niveaux d'imbrication de la base de données avec un trait d'union:

myblog.com-users 
myblog.com-posts 
myblog.com-comments 
anotherblog.com-users 
anotherblog.com-posts 
anotherblog.com-comments 
...hundreds more... 

Une autre solution serait de maintenir les bases de données de niveau inférieur et marquer chaque document avec la valeur de haut niveau:

utilisateurs de bases de données contenant un document User1, avec le champ instance = "test" ou un champ domain = "myblog.com"

Répondre

6

Je pense que vous utilisez abusivement la base de données de termes ici. Il n'y a aucune raison pour que vous ne puissiez pas stocker les données des utilisateurs, des publications et des commentaires dans une seule base de données couchdb. Vos vues couchdb peuvent séparer les documents utilisateur des documents posts, des documents de commentaires.

exemple fonction de carte pour les documents utilisateur dans une base de données CouchDB:

function(doc) { 
    if (doc.type = 'user') { // only return user documents 
    emit([doc.domain, doc.id], doc); // the returned docs will be sorted by domain 
    } 
} 

voir View Api des façons de limiter que les résultats de vues par domaine en utilisant startkey et endkey avec collation vue.

+1

En fait, je pense que vous utilisez abusivement le terme base de données. De CouchDB: The Definitive Guid: "Pour le strict, CouchDB est un système de gestion de base de données (DMS), ce qui signifie qu'il peut contenir plusieurs bases de données." Une base de données est un ensemble contenant des 'données connexes'. " Lorsque je me réfère à des bases de données dans ma question, je ne parle pas de plusieurs instances du DMS de CouchDB, mais plutôt de plusieurs compartiments pour contenir des données connexes. Étant donné qu'une base de données (compartiment) est destinée à contenir des données connexes, vous pouvez avoir un compartiment pour les commandes de tous les domaines ou vous pouvez en avoir un pour les utilisateurs et les commandes à partir d'un seul domaine. – rcampbell

+0

Au-delà de la terminologie, votre suggestion d'utiliser Views pour séparer les docs d'utilisateur, post-docs et docs de commentaire jives définitivement avec mon idée d'utiliser une paire clé/valeur discriminante pour chaque document. Pour moi, cela ressemble à un hack d'avoir à dire Post.domain = MyApp, User.domain = MyApp, Comment.domain = MyApp, etc. Beaucoup de duplication de données. En outre, il semble que la sécurité ne soit pas suffisante pour regrouper toutes les données client. Une vulnérabilité dans la vue peut exposer un client aux données d'un autre client. – rcampbell

+2

Mauvais choix de mots de ma part probablement. Mon point était que si vous voulez avoir des commentaires de commentaires et les utilisateurs tous dans une base de données qui est parfaitement bien. Avoir une base de données par domaine est probablement une bonne idée, mais si vous voulez assembler ou joindre les documents de publication et de commentaires, alors il serait plus facile de les garder tous dans la même base de données. –

3

Je pense que la meilleure solution est d'avoir une base de données par domaine, chaque stockage de données spécifiques au domaine.

Questions connexes