Pourquoi devrais-je utiliser une base de données documentaire au lieu d'une base de données relationnelle?
Pourquoi devrais-je utiliser une base de données documentaire telle que CouchDB au lieu d'une base de données relationnelle. Existe-t-il des types d'applications ou de domaines pour lesquels la base de données documentaire est plus adaptée que la base de données relationnelle?
Probablement vous ne devriez pas :-)
La deuxième réponse la plus évidente est de l’utiliser si vos données ne sont pas relationnelles. Cela se traduit généralement par l'absence de moyen simple de décrire vos données sous forme d'un ensemble de colonnes. Un bon exemple est une base de données dans laquelle vous stockez des documents papier, par exemple. en scannant le courrier du bureau. Les données sont numérisées PDF) 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, archivage jusqu'au, texte intégral OCRed, 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 mieux pour ce type de données que les bases de données relationnelles.
Personnellement, j’aime aussi le fait que je n’ai besoin d’aucune bibliothèque client pour CouchDB, sauf d’un client HTTP, qui est de nos jours inclus dans presque tous les langages de programmation.
La réponse probablement la moins évidente: restez avec ce système si vous ne ressentez aucune douleur. Si vous devez toujours travailler autour de votre SGBDR pour faire votre travail, une base de données orientée document peut être utile.
Pour une liste de contrôle plus élaborée cette annonce de Richard Jones .
CouchDB (à partir de 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 requièrent une API SQL beaucoup plus complexe. Ces API (JDBC, ODBC, etc.) sont souvent 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 éléments. 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 des conflits bidirectionnels. 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.
Possibilité d'interrogation et d'indexation, doté d'un moteur de génération 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 qu'un schéma.
- Distribué d'une manière qui semble simple et peu coûteuse.
Pour stocker et servir stupidement d'autres données de serveurs.
Ces dernières semaines, j'ai joué avec une application Lifestream qui interroge mes flux (Delicious, Flickr, Github, Twitter ...) et les stocke dans couchdb. La beauté de couchdb réside dans le fait qu’il me permet de conserver les données originales dans leur structure originale, sans surcharge. J'ai ajouté un champ 'classe' à chaque document, stockant le serveur source, et é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 plus, 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 d'applications vient à l'esprit.
Lorsque j'évolue constamment mon schéma, je suis constamment frustré de devoir le maintenir dans MySQL/SQLite. Bien que je n’ai pas encore fait beaucoup avec CouchDB, j’aime la simplicité avec laquelle il est possible de faire évoluer le schéma pendant le processus RAD.
Il peut arriver que vous ne souhaitiez pas utiliser une base de données non relationnelle lorsque vous avez beaucoup de relations plusieurs à plusieurs. Je n'ai pas encore compris comment créer de bonnes fonctions MapReduce autour de ce type 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 de CouchDB Map puissent appeler leurs propres requêtes dans la base de données, car cela pourrait potentiellement causer des boucles infinies.
Utilisez une base de données basée sur des documents 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 avez besoin de 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 à "modifier la table" au préalable. Les champs dans un document peuvent également contenir plusieurs éléments de données.