Je pense qu'actuellement, l'idée de NoSQL magasins de données et la notion de document de bases de données est donc de nouveau et de différent à partir des idées qui lecteur relationnelle de stockage qu'il y a actuellement très peu (le cas échéant) les meilleures pratiques.
Nous savons à ce stade que les règles pour le stockage de vos données au sein dire CouchDB (ou tout autre document de la base de données) sont assez différentes de celles du relationnel. Par exemple, il est à peu près un fait que la normalisation et à l'objectif d'3FN n'est pas quelque chose que l'on devrait s'efforcer d'atteindre. L'un des exemples est celui d'un simple blog.
Dans un magasin relationnel, vous avez un tableau pour chaque "Poste", "Commentaires" et "Auteurs". Chaque Auteur de nombreux Postes, et chaque Post aurait beaucoup de Commentaires. C'est un modèle qui fonctionne assez bien, et les cartes de beau sur tout relationnel. Toutefois, le stockage les mêmes données dans un docDB serait le plus susceptible d'être assez différente. Vous auriez probablement quelque chose comme une collection d'afficher les documents, dont chacune aurait son propre Auteur et la collecte de Commentaires intégré. Bien sûr, ce n'est probablement pas la seule façon pour vous de le faire, et c'est un peu un compromis (maintenant l'interrogation d'un seul poste est rapide, vous ne faites qu'une opération et tout remettre), mais vous n'avez aucun moyen de maintenir la relation entre auteurs et des postes (puisque tout devient une partie de l'après document).
Moi aussi, j'ai vu des exemples de décisions utilisation d'un attribut "type" (dans un CouchDB exemple). Bien sûr, cela sonne comme une approche viable. Est-il le meilleur? Je n'ai pas la moindre idée. Certainement dans MongoDB que vous souhaitez utiliser séparée des collections au sein d'une base de données, le type de l'attribut non-sens total. Dans CouchDB si... peut-être que c' est mieux. Les autres alternatives? Bases de données distinctes pour chaque type de document? Cela semble un peu cinglé, alors je me penche vers le "type" de la solution moi-même. Mais c'est juste moi. Peut-être il y a quelque chose de mieux.
Je me rends compte que j'ai divaguait un peu ici et dit très peu, probablement rien de ce que vous ne connaissez pas déjà. Mon point est-ce que - je pense que c'est à nous de l'expérience avec les outils que nous avons et les données que nous travaillons avec et au fil du temps les bonnes idées se répandre et devenir les meilleures pratiques en la matière. Je pense juste que vous demandez un peu trop tôt dans le jeu.
