Je pense qu'actuellement, toute l'idée des magasins de données NoSQL et le concept de bases de données de documents sont si nouveaux et différents des idées établies qui animent le stockage relationnel qu'il existe actuellement très peu (voire aucune) des meilleures pratiques.
Nous savons à ce stade que les règles de stockage de vos données dans CouchDB (ou toute autre base de données de documents) sont assez différentes de celles d'une base de données relationnelle. Par exemple, c'est à peu près un fait que la normalisation et l'objectif de 3NF ne sont pas quelque chose que l'on devrait rechercher. L'un des exemples courants serait celui d'un simple blog.
Dans un magasin relationnel, vous auriez une table pour "Messages", "Commentaires" et "Auteurs". Chaque auteur aurait de nombreux messages et chaque message aurait de nombreux commentaires. C'est un modèle qui fonctionne assez bien et qui correspond bien à n'importe quelle base de données relationnelle. Cependant, stocker les mêmes données dans une docDB serait probablement assez différent. Vous auriez probablement quelque chose comme une collection de documents Post, chacun ayant son propre auteur et sa propre collection de commentaires intégrés. Bien sûr, ce n'est probablement pas la seule façon de le faire, et c'est un peu un compromis (maintenant l'interrogation d'un seul article est rapide - vous n'effectuez qu'une seule opération et récupérez tout), mais vous n'avez aucun moyen de maintenir la relation entre les auteurs et les articles (puisque tout devient partie intégrante du document d'article).
J'ai moi aussi vu des exemples utilisant un attribut "type" (dans un exemple CouchDB). Bien sûr, cela semble être une approche viable. Est-ce le meilleur ? Je n'ai aucune idée. Certes, dans MongoDB, vous utiliseriez des collections séparées dans une base de données, ce qui rendrait l'attribut de type totalement absurde. Dans CouchDB cependant... peut-être que c'est meilleur. Les autres alternatives ? Des bases de données distinctes pour chaque type de document ? Cela semble un peu fou, donc je me pencherais moi-même vers la solution "type". Mais ce n'est que moi. Il y a peut-être quelque chose de mieux.
Je me rends compte que j'ai beaucoup parlé ici et que j'ai dit très peu de choses, très probablement rien que vous ne sachiez déjà. Ce que je veux dire, c'est que je pense que c'est à nous d'expérimenter avec les outils dont nous disposons et les données avec lesquelles nous travaillons et avec le temps, les bonnes idées se répandront et deviendront les meilleures pratiques. Je pense juste que vous demandez un peu trop tôt dans le jeu.
