Il y a plusieurs différences à considérer quand on fait la comparaison entre une base de données relationnelle et une base de données orientés document, y compris dans leurs tolérances face aux failles et la gestion de la concurrence. Ici je vais me concentrer sur les différences dans le modèle de données.

Les principaux arguments qui sont en avant pour privilégier une base de données orientés document c’est la flexibilité par rapport au schéma, une meilleure performance due à la localisation ( le fait de stocker des données spécifique à la meme endroit si elles sont fréquemment demandés …) et et le fait qu’il y ait une certaine similarité par rapport aux structures de donnés utilisés par certaines applications. Le modèle relationnel par contre offre des avantages sur une meilleure prise en compte des jointures et les supports sur les relations 1 à plusieurs et relations plusieurs à plusieurs.

Quel modèle de données est le moins couteux en lignes de codes ?

Si la donnée présent dans votre application a une structure qui s’apparente à un document ( par exemple un arbre d’une relation 1 à plusieurs), alors il est plus judicieux d’utiliser le modèle document. La technique qui consiste à éparpiller une structure de type document en plusieurs tables peut conduire à des schémas de données complexes et des lignes de codes supplémentaires en plus.

Le modèle document a quelques limitations, par exemple, vous ne pouvez pas faire référence directement à un élément imbriqué dans un document. Donc tant que les documents ne sont pas fortement imbriqués les uns les autres, alors ce n’est pas nécessairement un problème.

Le faible support pour les jointures dans les bases de données orientés document peut, ou ne peut pas être un problème. Cela dépend de l’application. Par exemple, il n’est pas utile d’utiliser les relations plusieurs à plusieurs dans une application qui utilise une base de données orientés document pour enregistrer des évènements associés à une heure.

Cependant, si votre application doit utiliser les relations plusieurs à plusieurs, alors le modèle de données document devient moins intéressant. Il est possible de réduire le besoin pour les jointures en dé-normalisant, mais en contrepartie, l’application doit se charger de fournir un travail supplémentaire pour maintenir la consistence de la données dé-normalisée.

En général, Il n’est pas possible de dire quel modèle de données conduira à un code moins complexe, ca va dépendre des relations qui existent entre les entités de données. Pour les données très interconnectés, le modèle de données document s’avère compliqué à mettre en place alors que le modèle relationnel est acceptable, et les modèles de données graphes le choix ultime !

Exemple : Gain en simplicité avec le code en SQL ( à gauche ) vs Cypher ( langue de requête orientés graphe à droite)

NextCog vous accompagne dans l’optimisation de vos bases de données transactionnelles et décisionnelles et la transition vers des bases de données non-relationnelles et graphes. Si vous voulez en savoir plus, prenez contact avec nous et nous vous ferons un devis approprié.