Architecture Couchdb: Vues ou documents?

Question

J'essaie d'apprendre CouchDB en travaillant à travers une simple application web de lecteur RSS. Les exigences sont les suivantes:

• permettent à chaque utilisateur d'importer X alimente à sa liste
• L'utilisateur peut ajouter des balises à chaque flux

• Pour chaque aliment conserve une liste des 50 derniers articles dans la base de données

• L'utilisateur doit obtenir une mise à jour chaque fois que le flux auquel il s'abonne lui ajoute de nouveaux éléments.

Après avoir lu divers guides et Principles for Modeling CouchDB Documents qui est une grande question connexe est ici que j'imagine que ce serait structuré:

• Flux

  • Nom
  • Dernière mise à jour

• Articles

  • FeedId
  • Titre
  • Texte

• utilisateurs

  • id
  • RSS: [feed1, feed2]
  • Tags: {funny: [article, article2]} // Peut-être un nouveau db aveC#userid #articleid #tagname?

Et pour chaque utilisateur, je créerais une vue avec les articles de l'alimentation et ajouter les balises à lui pour le présenter dans l'interface utilisateur.

Suis-je sur la bonne voie ici? Comment structureriez-vous cela?

Answer 1

Comme vous avez pu le voir, NoSQL est basé sur des compromis basés sur des scénarios d'utilisation. À un certain moment, vous devrez écrire des vues et des requêtes, et il n'y a pas de conception unique qui convient à tous.

Dans votre scénario, vous avez indiqué que chaque flux ne comportera que les 50 derniers articles, de sorte que les articles deviendront rapidement non pertinents (ainsi que toutes les données qui leur sont associées). Ainsi, si vous stockez les balises dans le modèle Utilisateur, vous devrez mettre à jour l'objet utilisateur trois fois: 1 lorsque l'utilisateur balise un article, 2 lorsque l'utilisateur supprime une balise et 3 lorsque l'article est périmé et supprimé. 3 est inévitable.

Il est préférable de stocker les étiquettes dans l'article, afin qu'ils soient supprimés avec l'article.

• Flux

  • Nom
  • Dernière mise à jour

• Articles

  • FeedId
  • Titre
  • texte
  • Tags: { "tag-1": [ "user1", "user2", ...], "tag2": [ "user3", "user4", ...]}

• utilisateurs

  • id
  • Flux: [feed1, feed2]

Vous pouvez voir que je stocke les tags regroupés par utilisateur. Vous pouvez également faire l'inverse { "user1" : "tag1", "user2" : "tag1", "user3" : "tag2", "user4" : "tag2", ... } si vous croyez que cela aide le traitement (en fonction de vos exigences de filtrage).

Answer 2

Je ne pense pas que votre design soit parfait pour CouchDB. En particulier, parce qu'il me semble que vous auriez à mettre à jour les documents de l'utilisateur beaucoup (pour mettre à jour les étiquettes d'article, surtout), et les documents de l'utilisateur deviendraient très importants au fil du temps.

Les interactions dans le modèle de lecteur RSS rendent effectivement ce problème pas très bon pour CouchDB. Vous devez conserver les tags par utilisateur, et vous (a) ne souhaitez pas les conserver dans le document utilisateur car vous devez mettre à jour le document utilisateur tout le temps, et (b) ne pas les conserver dans l'article documents parce que vous devez mettre à jour les documents de l'article tout le temps.

Je pense que ma solution idéale impliquerait des bases de données par utilisateur; cela rendrait le problème facilement traitable. Vous avez des documents de flux et des documents d'article et vous pouvez simplement conserver les balises de l'utilisateur dans les documents de l'article. Il y a beaucoup de duplication (parce que vous devez stocker des articles dans chaque base de données utilisateur), mais au moins c'est facile (et relativement rapide) d'interroger.