Pourquoi devrais-je utiliser une base de données basée sur des documents au lieu d'une base de données relationnelle?

Pourquoi devrais-je utiliser une base de données basée sur des documents comme CouchDB au lieu d'utiliser une base de données relationnelle. Existe-t-il des types typiques d'applications ou de domaines dans lesquels la base de données documentaire est plus appropriée que la base de données relationnelle?

Vous ne devriez probablement pas :-)

La deuxième réponse la plus évidente est que vous devriez l'utiliser si vos données ne sont pas relationnelles. Cela se manifeste généralement par l'absence de moyen simple de décrire vos données comme un ensemble de colonnes. Un bon exemple est une base de données dans laquelle vous stockez réellement des documents papier, par exemple en scannant le courrier de bureau. Les données sont le PDF numérisé et vous avez des métadonnées qui existent toujours (numérisées à, numérisées par, type de document) et de nombreux champs de métadonnées possibles qui existent parfois (numéro de client, numéro de fournisseur, numéro de commande, conservez-les jusqu'à ce que, Texte intégral OCR, etc.). En général, vous ne savez pas à l'avance quels champs de métadonnées vous allez ajouter au cours des deux prochaines années. Des choses comme CouchDB fonctionnent beaucoup plus bien pour ce type de données que les bases de données relationnelles.

J'aime aussi personnellement le fait que je n'ai pas besoin de bibliothèques clientes pour CouchDB à l'exception d'un client HTTP, qui est aujourd'hui inclus dans presque tous les langages de programmation.

La réponse probablement la moins évidente: si vous ne ressentez aucune douleur en utilisant un SGBDR, restez avec lui. Si vous devez toujours travailler autour de votre SGBDR pour faire votre travail, une base de données orientée document pourrait valoir le coup d'œil.

Pour une liste plus élaborée, consultez cette publication de Richard Jones .

CouchDB (depuis leur site Web )

• Un serveur de base de données de documents, accessible via une API JSON RESTful. En règle générale, les bases de données relationnelles ne sont pas simplement accessibles via les services REST, mais nécessitent une API SQL beaucoup plus complexe. Souvent, ces API (JDBC, ODBC, etc.) sont assez complexes. REST est assez simple.

• Ad-hoc et sans schéma avec un espace d'adressage plat. Les bases de données relationnelles ont un schéma complexe et fixe. Vous définissez des tables, des colonnes, des index, des séquences, des vues et d'autres choses. Couch ne nécessite pas ce niveau de planification avancée complexe, coûteuse et fragile.

• Distribué, avec réplication incrémentielle robuste avec détection et gestion bidirectionnelle des conflits. Certains produits commerciaux SQL offrent cela. En raison de l'API SQL et des schémas fixes, cela est complexe, difficile et coûteux. Pour Couch, cela semble simple et peu coûteux.

• Interrogable et indexable, avec un moteur de création de rapports orienté table qui utilise Javascript comme langage de requête. Il en va de même pour SQL et les bases de données relationnelles. Rien de nouveau ici.

Alors. Pourquoi CouchDB?

• REST 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ûteuse.

Pour stocker et servir stupidement les données d'autres serveurs.

Ces dernières semaines, j'ai joué avec une application lifestream qui interroge mes flux (délicieux, flickr, github, twitter ...) et les stocke dans couchdb. La beauté de couchdb est qu'il me permet de conserver les données d'origine dans leur structure d'origine sans frais généraux. J'ai ajouté un champ «classe» à chaque document, stockant le serveur source, et j'ai écrit une classe de rendu javascript pour chaque source.

En général, chaque fois que votre serveur communique avec un autre serveur, un stockage sans schéma est préférable car vous n'avez aucun contrôle sur le schéma. En prime, couchdb utilise les protocoles natifs des serveurs et des clients - JSON pour la représentation et HTTP REST pour le transport.

Le développement rapide des applications vient à l'esprit.

Lorsque j'évolue constamment mon schéma, je suis constamment frustré de devoir maintenir le schéma dans MySQL / SQLite. Bien que je n'ai pas encore fait trop avec CouchDB, j'aime la simplicité de l'évolution du schéma pendant le processus RAD.

Un cas où vous ne voudrez peut-être pas utiliser une base de données non relationnelle est lorsque vous avez beaucoup de relations plusieurs-à-plusieurs; Je n'ai pas encore compris comment créer de bonnes fonctions MapReduce autour de ces types de relations, en particulier si vous avez besoin de métadonnées dans la relation de jonction. Je ne suis pas sûr, mais je ne pense pas que les fonctions CouchDB Map peuvent appeler leurs propres requêtes sur la base de données, car cela pourrait potentiellement provoquer des boucles infinies.

Utilisez une base de données documentaire 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 comme un 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 qu'il soit nécessaire de «modifier la table» au préalable. Les champs basés sur des documents peuvent également contenir plusieurs éléments de données.

Pour élaborer sur smdelfin: flexibilité. Vous pouvez stocker des données dans n'importe quelle structure (étant non structurée et tout) et chaque document peut être complètement différent. CouchDB est particulièrement utile car avec leurs index de «vue», vous pouvez filtrer des documents spécifiques et interroger uniquement cette vue lorsque vous voulez ces sous-ensembles de votre base de données.

Mon plus gros point gagnant des bases de données documentaires qui stockent des données au format JSON: c'est le format natif de JavaScript. Par conséquent, les applications Web JavaScript fonctionnent incroyablement bien avec CouchDB. J'ai récemment créé une application Web qui utilise CouchDB et elle est très rapide tout en étant capable de gérer une structure de données qui varie constamment.

Les bases de données basées sur des documents ont un gros avantage par rapport aux bases de données relationnelles car elles ne nécessitent pas de définir un schéma à l'avance - avant de pouvoir entrer des données.

En outre, vous devez utiliser une base de données de documents si vos données ne sont pas relationnelles et ne peuvent pas être stockées dans une table mais sont plutôt un ensemble d'images, ou par exemple des articles de journaux.

Un autre avantage est la facilité d'utilisation des bases de données documentaires dans le développement Web. Pour plus de détails sur les modèles de base de données NoSQL, consultez cette source: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf