Discussion :

[landry161]

Bonjour,

Salaheddine Babouche de la société Palo IT (http://www.palo-it.com/blog) vous propose un tutoriel sur la modélisation d'un schéma d'une base de données NoSQL orientée document.

Vous trouverez cet article à cette adresse : http://paloit.developpez.com/tutorie...ntee-document/

Profitez de cette discussion pour laisser vos commentaires.

Mickael

Bonjour Salaheddine Babouche je suis moi même en train de rédiger en ce moment mon article sur le NoSQL ( mongodb). Tu as énuméré certains points tels que la dénormalisation et surtout la scalabilité. Je l'ai deja téléchargé et je compte même l'ajouter en référence dans mon article.

Bravo.

[jdesodt]

Bonsoir,
Vous me trouverez un peu bavard, mais je souhaiterais comprendre ce qu’est un système de gestion de documents afin de le comparer avec la théorie relationnelle à laquelle j’adhère (attention ! ne pas confondre relationnel et SQL qui n’en est qu’un avatar plus ou moins conforme).
...
Maintenant, si ’ai été sévère avec Salaheddine, je suppose quand même que la modélisation orientée document va plus loin que les deux petits exemples qu’il a fournis et que les systèmes fournissent des primitives formellement décrites pour manipuler les documents, qu’elles soient ensemblistes ou non. Quant à l’intégrité des données, je pense avoir donné un point de vue suffisant, au nom de la défense de la validité et la crédibilité des bases de données et j’aimerais savoir comment des systèmes tels que MongoDB permettent, à l’instar de DB2 d’empêcher les erreurs que j’ai données en exemple (mais à vous lire, j’ai cru comprendre que ces systèmes bottent en touche...)
Pour que nous, les bougres qui découvrons le sujet traité par Salaheddine Babouche, puissions mieux comprendre de quoi il retourne, je suggère que celui-ci (ou quelqu’un d’autre s’il n’en a pas le temps) fournisse quelque chose de plus consistant en termes de structure de base de données, des opérateurs et les contraintes d’intégrité. En l’occurrence, je propose le sujet suivant, inspiré de l’actualité hippique :
« Les courses de galop plat en France »
...

Excusez cette réponse tardive, mais je viens seulement de tomber sur ce post.

Bonjour fsmrel,

Au vu de vos explications précises et documentées, je devine en vous un grand expert en BDD Relationnelles.
J'ai pratiqué de nombreuses années dans ce domaine. Depuis, je me suis mis au NoSQL pour certains projets.
Votre proposition hippique m'interpelle, et je ne crois pas me tromper en répondant que, pour le besoin de votre exemple, une Base NoSQL Document est nettement moins bien adaptée qu'une Base NoSQL Graphe.

Je vous invite à aller voir OrientDB, qui est à la fois une Base Graphe ET une Base Document.
Cette base OrientDB répond aux contraintes ACID, et on y trouve de la gestion de Hooks qui permet d'assurer l'intégrité de la base.

Je ne suis pas un commercial de OrientDB ni un de leurs consultants, mais un utilisateur heureux depuis la version 1.3 (ils en sont à la version 2.0.x).
Je pense que ce modèle de base répondrait à votre problèmatique hippique. Si vous le souhaitez, (et en m'accordant un peu de temps... ;) je peux vous fournir le schéma du graphe qui devrait correspondre.
Et pour les performances de la base OrientDB : c'est de la bombe.
C'est un peu hors sujet par rapport au titre initial de modélisation orientée document, mais si ça peut faire avancer le débat.

[SQLpro]

Vous demandez quelle algèbre relationnel est utilisé.

Il a demandé quel algèbre. Il n'a pas suggéré que c'était l'algèbre relationnelle. N'oubliez que l'ordinateur (et tout ce qui va avec) est un outil mathématique... Donc la question est bien celle de la théorie et donc des opérateurs algébriques utilisés....

A +

[SQLpro]

[I]...
Et pour les performances de la base OrientDB : c'est de la bombe

cédelabombe est un nouvel acteur dans le domaine des benchmarks comparatif ?

A +

[hugo123]

Ah monsieur "petites remarques assassines" vient de débarquer sur le sujet. C'est le moment de le clore...
En dehors de faire remarquer que les personnes ne savent pas lire ou qu'ils disent des conneries, vous avez des remarques intéressantes pour la discussion ?

[fallphenix]

J'ai lu l'ensemble des réponses faites sur le sujet et je trouve que c'est très intéressant de confronter ces deux types d'approches.
Je dirais pour ma part que que les NoSQL sont un autre type d'approche permettant d'avoir plus de performances dans la gestion des données.

Entre la normalisation :
Division des données en plusieurs collections référencée les uns des autres. Chaque morceau (document) de données (il faut comprendre le terme morceau de données comme l'a expliqué

DDD va un peu plus loin. Ce n'est pas juste un découpage par entités (personnes, contrats, cotisations) mais par cas d'usage (on peut retrouver les mêmes entités plusieurs fois mais sous différentes formes).

). Donc chaque morceau de données vit dans une collection pouvant être référencée par d'autre documents. Ainsi, pour modifier les données, un seul document doit être mis à jour. Cependant pour faire des opérations de jointures, il faudra faire autant de requête nécessaire.

Et la dénormalisation :
Le contraire de la normalisation: l'intégration de toutes les données en un seul document. Il s'agira donc de faire dupliquer les données dans les différents documents. Par conséquent, pour les opérations d'Update, plusieurs documents auront besoin d'être mise à jours (très utile dans certains cas : consistance). Néanmoins toutes les données connexes peuvent être récupérés avec une seule requête (gain de performance).

On peut aussi utiliser les deux approches simultanément (II-B. Duplication d'un sous ensemble de champs).
exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
Auteur 
{ 
    "id": 10, 
    "nom": "dupont", 
    "prenom": "david", 
    "livres": { 
           "_id" : ObjectId("512512f0d86041c7dca81919"),
          "titre" : "bla bla bla",
          "genre": "informatique", 
           "tags":["informatique","bigdata","nosql"], 
          "chapters" : [1,2,3,4]
     } 
 
} 
Livre 
{ 
    "_id": 512512f0d86041c7dca81919, 
    "like": "2103",  
    "unlike": "3",  
 
 
}

[Booster2ooo]

Cet article est extrêmement pauvre, j'ai du mal à comprendre pourquoi il est si bien noté.

Heureusement que la discussion qui s'en suit est un peu plus intéressante.

[KiLVaiDeN]

Bonjour!

Il m'a été confié la tâche d'interfacer une application existante à une BDD de type "NoSQL" (MongoDB).

Je viens du monde "relationnel", et en faisant des recherches pour me documenter, je suis tombé sur cette discussion où des interrogations à la fois pertinentes et cruciales ont été soulevées.

Il semblerait que l'intégrité référentielle est essentielle dans certains cas (par exemple celui des données salariales, ou bancaires) et superflue dans d'autres (par exemple l'enregistrement des logs serveurs).

En fonction des besoins, il convient donc de choisir le bon SGBD, en gardant en tête que le "NoSQL" n'assure pas d'intégrité référentielle, et décharge cette couche à l'application qui devra la gérer selon ses besoins, mais attention cela est potentiellement source d'erreurs et de bugs qui pourraient compromettre la stabilité des données. Les SGBD "classiques" sont spécialisés dans la gestion de cette intégrité référentielle et il serait dommage de s'en priver si celle-ci est cruciale pour l'application cible.

Si l'intégrité référentielle est importante, il faut donc utiliser un SGBD assurant sa prise en charge, et l'exemple des BDD de type graphe me semble également pertinent dans ce contexte en plus des SGBD "classiques".

Je me pose cependant une question quant à l'utilisation d'un SGBD type "NoSQL" : la mise à jour (UPDATE) ou la suppression (DELETE) doivent-ils être gérés "complètement" ?
Si l'objectif d'un "NoSQL" est de fournir des collections complètes sans nécessité de procéder à des jointures, cela ne signifie-t-il pas qu'il faille plutôt créer sans cesse des nouveaux enregistrements, et "désactiver" les anciens ? (En mettant éventuellement un système de purge ou d'archivage en place, si besoin)

La duplication des données devient un "paradigme" intrinsèque à l'utilisation des BDD de type "NoSQL" ce qui semble poser problème en cas de mise à jour des données, notamment lorsque celles-ci sont localisés à divers endroits du schéma. D'où mon questionnement. Ne peut-on pas s'en passer ?

Merci en tout cas pour vos interventions qui sont riches en partage et en expérience, j'admire celles et ceux qui n'hésitent pas à donner les fruits de leur expérience aux autres, je crois que c'est par ce type de dons que nous pourrons améliorer notre condition globale humaine!