J'ai une question à laquelle j'essaie de répondre depuis un certain temps maintenant mais je n'arrive pas à comprendre:
Comment concevez-vous ou divisez-vous les documents CouchDB?
Prenons un article de blog par exemple.
La manière semi "relationnelle" de le faire serait de créer quelques objets:
- Publier
- Utilisateur
- Commentaire
- Marque
- Fragment
Cela a beaucoup de sens. Mais j'essaie d'utiliser couchdb (pour toutes les raisons que c'est génial) pour modéliser la même chose et cela a été extrêmement difficile.
La plupart des articles de blog vous donnent un exemple simple de la façon de procéder. Ils le divisent fondamentalement de la même manière, mais disent que vous pouvez ajouter des propriétés «arbitraires» à chaque document, ce qui est vraiment bien. Donc vous auriez quelque chose comme ça dans CouchDB:
- Message (avec des balises et des extraits de modèles "pseudo" dans le document)
- Commentaire
- Utilisateur
Certaines personnes diraient même que vous pouvez y ajouter le commentaire et l'utilisateur, donc vous auriez ceci:
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author: {
name: "Lance"
age: "23"
}
tags: ["sample", "post"]
comments {
comment {
id: 93930414809
body: "Interesting Post"
}
comment {
id: 19018301989
body: "I agree"
}
}
}
Cela semble très joli et facile à comprendre. Je comprends également comment vous pouvez écrire des vues qui n'extraient que les commentaires de tous vos documents de publication, pour les intégrer dans des modèles de commentaires, de même avec les utilisateurs et les balises.
Mais alors je pense, "pourquoi ne pas simplement mettre tout mon site dans un seul document?":
site {
domain: "www.blog.com"
owner: "me"
pages {
page {
title: "Blog"
posts {
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author: {
name: "Lance"
age: "23"
}
tags: ["sample", "post"]
comments {
comment {
id: 93930414809
body: "Interesting Post"
}
comment {
id: 19018301989
body: "I agree"
}
}
}
post {
id: 18091890192984
title: "Second Post"
...
}
}
}
}
}
Vous pourriez facilement faire des vues pour trouver ce que vous vouliez avec cela.
Alors la question que j'ai est, comment déterminez-vous quand diviser le document en plus petits documents, ou quand établir des "RELATIONS" entre les documents?
Je pense que ce serait beaucoup plus "orienté objet", et plus facile à mapper aux objets de valeur, s'il était divisé comme suit:
posts {
post {
id: 123412804910820
title: "My Post"
body: "Lots of Content"
html: "<p>Lots of Content</p>"
author_id: "Lance1231"
tags: ["sample", "post"]
}
}
authors {
author {
id: "Lance1231"
name: "Lance"
age: "23"
}
}
comments {
comment {
id: "comment1"
body: "Interesting Post"
post_id: 123412804910820
}
comment {
id: "comment2"
body: "I agree"
post_id: 123412804910820
}
}
... mais ensuite cela ressemble plus à une base de données relationnelle. Et souvent, j'hérite de quelque chose qui ressemble au "site entier-dans-un-document", il est donc plus difficile de le modéliser avec des relations.
J'ai lu beaucoup de choses sur comment et quand utiliser les bases de données relationnelles par rapport aux bases de données de documents, ce n'est donc pas le problème principal ici. Je me demande plus simplement quelle est la bonne règle / principe à appliquer lors de la modélisation de données dans CouchDB.
Un autre exemple est celui des fichiers / données XML. Certaines données XML ont une imbrication de plus de 10 niveaux de profondeur, et j'aimerais visualiser cela en utilisant le même client (Ajax on Rails par exemple, ou Flex) que je voudrais rendre JSON à partir d'ActiveRecord, CouchRest ou de tout autre mappeur relationnel d'objets. Parfois, j'obtiens d'énormes fichiers XML qui représentent la structure entière du site, comme celui ci-dessous, et je devrais le mapper aux objets de valeur à utiliser dans mon application Rails afin de ne pas avoir à écrire une autre façon de sérialiser / désérialiser les données :
<pages>
<page>
<subPages>
<subPage>
<images>
<image>
<url/>
</image>
</images>
</subPage>
</subPages>
</page>
</pages>
Les questions générales de CouchDB sont donc:
- Quelles règles / principes utilisez-vous pour diviser vos documents (relations, etc.)?
- Est-il acceptable de mettre tout le site dans un seul document?
- Si tel est le cas, comment gérez-vous la sérialisation / désérialisation de documents avec des niveaux de profondeur arbitraires (comme le grand exemple json ci-dessus ou l'exemple xml)?
- Ou ne les transformez-vous pas en VO, décidez-vous simplement "ceux-ci sont trop imbriqués dans Object-Relational Map, donc je vais simplement y accéder en utilisant des méthodes XML / JSON brutes"?
Merci beaucoup pour votre aide, la question de savoir comment diviser vos données avec CouchDB a été difficile pour moi de dire "voici comment je dois le faire à partir de maintenant". J'espère y arriver bientôt.
J'ai étudié les sites / projets suivants.
- Données hiérarchiques dans CouchDB
- Wiki CouchDB
- Canapé - Application CouchDB
- CouchDB Le guide définitif
- PeepCode CouchDB Screencast
- CouchRest
- CouchDB README
... mais ils n'ont toujours pas répondu à cette question.