Vous avez besoin de penser à la façon dont vous vous approchez de l'application dans un document. Si vous essayez simplement de reproduire la façon dont vous permettrait de modéliser le problème dans un SGBDR alors vous allez échouer. Il y a aussi différents arbitrages que vous pourriez faire. (ndlr: vous ne savez pas comment cela est lié à l'argument, mais:] Souvenez-vous que CouchDB conception suppose que vous allez avoir un cluster actif de nombreux nœuds qui peuvent échouer à tout moment. Comment est votre application va gérer l'un de la base de données des nœuds en train de disparaître sous elle?)
Une façon de penser, c'est d'imaginer que vous n'en avons pas les ordinateurs, les documents sur papier. Comment voulez-vous créer une entreprise efficace processus à l'aide de bouts de papier, étant passé autour? Comment pouvez-vous éviter les goulots d'étranglement? Que faire si quelque chose va mal?
Sous un autre angle que vous devriez penser est la cohérence des résultats, où vous pourrez monter dans un état cohérent, mais finalement vous avez peut-être incompatible pour une certaine période de temps. C'est une abomination dans les SGBDR terre, mais très courante dans le monde réel. L'canonique transaction exemple est de transférer de l'argent à partir de comptes bancaires. Comment est-ce réellement se produire dans le monde réel, par le biais d'un seul transactions atomiques ou par le biais de différentes banques d'émission de crédit et de débit, des avis? Ce qui se passe quand vous écrivez un chèque?
Donc, permet de regarder vos exemples:
- CRUD des entités avec quelques champs avec un index unique sur elle.
Si je comprends bien dans CouchDB termes, vous voulez avoir une collection de documents où certains nommé valeur est garanti d'être unique à travers tous ces documents? Ce cas n'est généralement pas justifiée car les documents peuvent être créés sur les différentes répliques.
Nous avons donc besoin de regarder le monde réel problème et voir si nous pouvons le modèle. Avez-vous vraiment besoin d'eux pour être unique? Votre application peut gérer plusieurs documents avec la même valeur? Avez-vous besoin d'attribuer un identifiant unique? Pouvez-vous le faire de façon déterministe? Un scénario commun, lorsque cela est requis est l'endroit où vous avez besoin d'un séquentiel unique d'identification. C'est difficile à résoudre dans un environnement répliqué. En fait, si l'identifiant unique est nécessaire pour être strictement séquentielle par rapport au temps créé c'est impossible si vous avez besoin de l'id tout de suite. Vous avez besoin de vous détendre au moins une de ces contraintes.
- ecommerce web app comme ebay
Je ne suis pas sûr de ce qu'il faut ajouter ici que le dernier commentaire que vous avez fait sur ce poste a été de dire "très utile! grâce". Y avait-il quelque chose de manquant dans l'approche décrite là c'est encore vous causer un problème? J'ai pensé MrKurt la réponse a été assez complet et j'ai ajouté un peu de mise en valeur qui permettrait de réduire les conflits.
