Comparaison MongoDB, SQL
Tableau comparatif entre les terminologies Mongo et celles du SQL
SQL | MongoDB |
---|---|
database | database |
table | collection |
enregistrement | document |
colonne | champ |
index | index |
jointure | objet, dénormalisation |
clef primaire | clef primaire (Dans MongoDB la clef primaire est automatiquement attribué au champ _id) |
clef étrangère | reférence |
Il est toujours possible de passer d'une BDD SQL à une BDD MongoDB et vice versa, avec plus ou moins de difficultés.
Dans MongoDB les données prennent la forme de documents enregistrés dans des collections, sans schéma prédéterminé. En d'autres termes, des champs peuvent être ajoutées à un document à tout moment champ reconfiguration de la collection
Supposons qu'on est la collection actors avec les documents suivants :
{lastName : "Good", firstName : "Meagan"}
{lastName : "Fox", firstName :"Meagan"}
On peut ensuite faire un db.actors.update({lastName: "Good"} , {$set : {good:true}}). Notre collection devien donc :
{lastName : "Good", firstName : "Meagan", good :true}
{lastName : "Fox", firstName :"Meagan"}
Nous avons ainsi réussi à ajouter un nouveau champ à seulement un de nos documents, ce qui nous permet d'avoir en même temps deux documents de schémas différents dans une même collection.
l ne serait pas possible d'avoir le même résultat en SQL car tous les enregistrements d'une table ont les mêmes champs.
Les jointures n'existent pas dans MongoDB. Les données sont dénormalisées.
Toutes les informations relatives à un objet sont stockées dans un même document, ce qui permet de faire toutes les requêtes nécessaires sur le même document pour récupérer les données.
Prenons l'exemple de films et d'acteurs
Dans une base de données relationnelle nos données seront présentées sous la forme suivante :



Dans MongoDB les données seront stockées de cette manière



Pour récupérer le casting d'un film par exemple, dans le premier cas on est obligé de faire une requête avec des jointures sur les trois tables alors que dans MongoDB chaque document correspond dans notre exemple à un film avec son casting entier. Il n'est plus nécessaire de faire de jointures afin de récupérer les informations sur un film. Les deux syntaxes :
SQL : SELECT af.nom, fa.prenom from Film f, acteur a, Film_acteur fa where f.nom="The Godfather pt2" and fa.id_film=f.id and fa.id_acteur=a.id
MongoDB: db.movies.find({nom :"The Godfather pt2"}, {'acteurs.nom' :1, 'acteurs.prenom' :1})
Comme en SQL le concept de clef primaire existe dans MongoDB. Chaque document est identifié par la valeur de son champ "_id". Sa valeur doit être une collection et peut prendre tout type de données BSON sauf un tableau. Il est toujours le premier champ d'un document.
Il est toutefois possible de référencé un document dans un autre document. Pour récupérer toutes les données liées au document référencé, il sera alors nécessaire de faire deux requêtes séparées. |
On utilisera souvent la première méthode si on privilégie l'intégrité des données sur la rapidité d'accès.
Avantages du MongoDB
Plus proche des langages de programmation
très flexible grâce à l'orientation documents
Possibilité d'avoir des documents de schémas différents dans une même collection ("Schemaless"), ce qui est pratique au début d'un projet par exemple car on est souvent amener à changer de schémas
accès aux données plus rapides que le SQL par l'absence de jointures
facile de gérer de très grandes quantités de données grâce au scaling (répartitions du moteur de base de données sur plusieurs ordinateurs)
la console mongo exécute du code JavaScript, ce qui est pratique pour insérer des données avec des fonctions JavaScript
Limites de MongoDB
Le prix à payer pour la flexibilité est la non existence de clefs étrangères. Cela nous oblige à contrôler l'intégrité des données dans la couche application.
À cause de la dénormalisation, on est exposé à la redondance.
Si on reprend notre exemple sur les films, on serait obliger d'enregistrer un acteur dans chacun des films dans lesquels il jouerait.
Complément :
MongoDB hérite aussi de tous les avantages et les limites du JSON.