Pourquoi devrais-je utiliser le document à partir de base de données comme CouchDB au lieu d’utiliser la base de données relationnelle. Y a-t-il des n’importe quels genres typiques des applications ou des domaines où la base de données documentaire basé convient mieux que la base de données relationnelle ?
Réponses
Trop de publicités?
mdorseif
Points
7473
Probablement, vous ne devez pas :-)
La deuxième plus évidente est que vous devez utiliser si vos données n'est pas relationnelle. Ce manifeste habituellement en ayant pas de moyen facile de décrire vos données comme un ensemble de colonnes. Un bon exemple est une base de données de l'emplacement où vous stockez des documents papier, par exemple par le bureau de numérisation de courrier. Les données est le fichier PDF numérisé et vous avez des méta-données qui existe toujours (scannés, numérisés par type de document) et beaucoup de possibles champs de métadonnées qui existe parfois (numéro de client, numéro de fournisseur numéro de commande, garder le fichier jusqu'à ce que, sous roc fulltext, etc). Habituellement, vous ne savez pas à l'avance lequel des champs de métadonnées que vous allez ajouter dans les deux prochaines années. Des choses comme CouchDB de travail beaucoup plus agréable pour ce genre de données, de bases de données relationnelles.
J'ai aussi adore le fait que je n'ai pas besoin des bibliothèques clientes pour CouchDB sauf un client HTTP, qui est aujourd'hui inclus dans presque tous les langages de programmation.
Le probablement la moins évidente réponse: Si vous ne sentez pas la douleur à l'aide d'un SGBDR, rester avec elle. Si vous avez toujours de travailler autour de votre SGBDR pour faire votre travail, une base de données orientée document pourrait être utile à un look.
Pour une description plus détaillée de la liste de vérification de la présente publication de Richard Jones.
S.Lott
Points
207588
CouchDB (à partir de leur site web)
Un document de serveur de base de données, accessible via un RESTful API JSON. Généralement, les bases de données relationnelles ne sont pas accessible simplement via des services REST, mais nécessite beaucoup plus complexe API SQL. Souvent, ces API (JDBC, ODBC, etc.) sont assez complexes. RESTE est assez simple.
Ad-hoc et le schéma-gratuit avec un espace d'adressage à plat. Les bases de données relationnelles complexes, un schéma fixe. Vous définissez des tables, des colonnes, des index, des séquences, des points de vue et d'autres choses. Canapé n'a pas besoin de ce niveau de complexe, coûteux, fragile de planification avancée.
Distribué, mettant en vedette robuste, différentiels de réplication bi-directionnelle détection et gestion des conflits. Certains SQL produits commerciaux. En raison de l'API SQL et le fixe, des schémas, c'est complexe, difficile et coûteux. Pour le Canapé, il semble simple et peu coûteux.
Requête-mesure et index-mesure, doté d'une table orientée moteur de génération de rapports qui utilise du Javascript, un langage de requête. Afin de SQL et des bases de données relationnelles. Rien de nouveau ici.
. Pourquoi CouchDB?
- Le REPOS est plus simple que JDBC ou ODBC.
- Aucun Schéma n'est plus simple que le Schéma.
- Distribué d'une manière qui semble simple et peu coûteux.
daonb
Points
561
Pour bêtement stocker et servir les autres serveurs de données.
Dans les deux dernières semaines, j'ai joué avec un courant de vie application qui interroge mes flux (delicious, flickr, github, twitter...) et les stocke dans couchdb. La beauté de couchdb est qu'il me permet de garder les données d'origine dans sa structure d'origine, avec pas de frais généraux. J'ai ajouté un champ "classe" pour chaque document, le stockage du serveur source, et a écrit un script javascript rendu de la classe pour chaque source.
La généralisation, à chaque fois que votre serveur communique avec un autre serveur un schéma de stockage est le meilleur que vous n'avez aucun contrôle sur le schéma. Comme un bonus, couchdb utilise le natif de protocoles de serveurs et de clients - JSON pour la représentation et la HTTP REPOS pour le transport.
pixelcort
Points
414
Développement d'application rapide qui vient à l'esprit.
Quand je suis en constante évolution de mon schéma, je suis constamment frustré par avoir à maintenir le schéma dans MySQL/SQLite. Alors que je n'ai pas fait de trop avec CouchDB pourtant, je n'aime pas comment il est simple de faire évoluer le schéma lors de la SAR processus.
Un cas où vous ne souhaitez pas utiliser une base de données non relationnelle, c'est quand vous avez beaucoup de plusieurs-à-plusieurs liens; je n'ai pas encore d'obtenir ma tête autour de la création d'une bonne MapReduce fonctions autour de ces types de relations, en particulier si vous avez besoin d'avoir des métadonnées dans l'adhésion à la relation. Je ne suis pas sûr, mais je ne pense pas que CouchDB les fonctions de Mappage peuvent appeler leurs propres requêtes sur la base de données, depuis, ce qui pourrait provoquer une boucle infinie.
smdelfin
Points
41
Utilisez une base de données basée sur un document lorsque vous n'avez pas besoin de stocker des données dans des tables avec des champs de taille uniforme pour chaque enregistrement. Au lieu de cela, vous devez stocker chaque enregistrement en tant que document présentant certaines caractéristiques. N'importe quel nombre de champs de n'importe quelle longueur peut être ajouté dynamiquement à un document à tout moment sans avoir besoin de "modifier la table" en premier. Les champs dans document peuvent également contenir plusieurs éléments de données.
