SlideShare une entreprise Scribd logo
1  sur  13
Télécharger pour lire hors ligne
SGBDR	vs	NOSQL
Différences	et	« Uses	Cases »
(ou	dans	quels	cas	utiliser	l’un	plutôt	que	l’autre	au-delà	de	l’effet	de	mode	;p)
- Présentation	par	Eric	DYKSTEIN	le	19	Avril	2018	@	Epitech,	Montpellier	-
Montpellier
Qu’est-ce	que	le	NOSQL	?
Montpelllier
Qu’est-ce	que	le	NOSQL	?
• Acronyme	créé	en	2009	:	« Not	Only SQL »	->	il	n’y	a	pas	que	le	SQL	dans	la	vie	;)	!
• Moteurs	de	stockage	de	bases	de	données	plus	que	« Systèmes	de	Gestion »	:
→ Données	stockées	de	manière	non	structurée	(chaque «	record » peut	contenir	des	champs	≠	)	
→ Aucun	contrôle	sur	l’intégrité	des	données	(aucune	règle	d’écriture	applicable	->	les	propriétés	
« cohérence »	et/ou	« isolation »	du	concept	ACID ne	sont	généralement	pas	respectées)
→ Aucun	système	d’intégrité	référentielle	des	données	entre	«	entités »	différentes.
→ Systèmes	de	requêtage des	données	plus	ou	moins	élaborés
• 4	familles	/	types	de	moteurs	de	stockage	distincts	:	
→ Clés	/	valeurs	(ex	:	Redis,	DynamoDB,	Voldemort)
→ Colonnes (ex	:	Cassandra,	BigTables,	Hbase)
→ Documents (ex	:	MongoDB,	CouchDB,	CouchBase)
→ Graphe (ex	:	Neo4j)
Montpelllier
Pourquoi	le	NOSQL	?
Montpelllier
Pourquoi	le	NOSQL	?
• Pour	répondre	à	des	problématiques	spécifiques	de	performance	:	
→ En	cas	de	très	grosse	volumétrie	de	données
→ En	cas	de	très	grosses	montées	en	charges	(sites	à	fort	trafic)
vLes	moteurs	NOSQL	sont	plus	rapides	en	lecture	et	en	écriture	qu’un	SGBDR	classique	car	ils	
n’effectuent	aucun	contrôle	sur	les	données,	la	plupart	peuvent	charger	leurs	données	en	
mémoire	vive	et/ou	être	répartis	sur	plusieurs	serveurs	en	parallèle	(sharding).
• Pour	répondre	à	des	problématiques	fonctionnelles	spécifiques	:
→ Designer	une	base	de	donnée	pour	développer	un	système	de	gestion	du	cache	(modèle	Clés	/	
Valeurs)
→ Designer	une	base	de	données	à	la	structure	« super	flexible »	pour	la	réalisation	d’un	POC	ou	
d’un	MVP	(modèles	Documents et	Colonnes)
→ Designer	une	base	de	données	à	nœuds	multiples	(type	réseau	social	via	le	modèle	Graphe)
→ Designer	une	base	de	données	pour	se	lancer	dans	l’aventure	« Big Data »	<(-_-)>
Montpelllier
Les	bases	de	données	de	type	Clé	/	Valeur
• Elles	permettent	un	stockage	de	paires	« clé	/	valeur »	:	la	clé	identifie	
l’enregistrement,	la	valeur	étant	la	(ou	les	données)	elle(s)-même(s)	
qui	est/sont	gérée(s)	de	manière	« opaque »	->	le	type	de	donnée(s)	
est	indéterminé	et	stocké	généralement	de	manière	binaire.
• Elles	offrent	une	large	flexibilité	concernant	le	type	de	donnée(s)	à	
stocker	:	il	peut	s’agir	d’une	simple	chaine	de	caractère,	ou	de	tout	
autre	type	de	données	tel	un	objet	JSON	ou	des	données	binaires	
(image,	vidéo,	exécutable,	etc…).
• Elles	stockent	les	données	en	mémoire	vive	lorsqu’elles	sont	actives	
afin	d’obtenir	des	temps	de	réponses	très	rapides.
Montpelllier
Les	bases	de	données	de	type	Colonnes
• Type de BDD le plus proche des SGBDR en terme de structuration de données :
Nous avons à faire à des lignes et des colonnes contenues dans des Tables -> Sauf
que les colonnes sont créées pour chaque ligne et qu’elles ne sont pas décrites
structurellement dans la définition de la Table.
• Une colonne n’existe donc pas tant qu’une donnée n’a pas été enregistrée en
base et la manière dont celles-ci sont stockées s’apparente à une paire « clé /
valeur » où la clé est le nom de la colonne et la valeur est la donnée que l’on veut
exploiter.
• Ainsi, les données ne seront pas stockées par ligne mais par colonne -> Objectif
pouvoir faire des traitements sur des colonnes spécifiques et non sur des lignes
complètes pour un balayage des données par colonne plus rapide.
Montpelllier
Les	bases	de	données	de	type	Documents
• Type	de	BDD	NOSQL	le	plus	populaire,	notamment	grâce	à	MongoDB
• Stockage	des	données	dans	des	collections	de	documents	->	Par	rapport	aux	bases	de	
données	relationnelles,	les	collections	sont	aux	tables	ce	que	les	documents	sont	aux	
enregistrements.	
• Les	données	sont	généralement	formatées	en	JSON ->	pratique	à	manipuler	avec	du	
JavaScript,	d’où	le	célèbre	couplage	« NodeJS /	MongoDB »
• Possibilité	de	stocker	tous	types	de	données	« primitives »	dans	une	collection	(boolean,	
number,	string),	mais	aussi	des	tableaux	de	données	ou	des	objets	JSON	contenant	eux-
mêmes	des	données	de	tous	types	->	possibilité	de	créer	des	arborescences	de	données	
complexes	dans	un	document.
• Exemple	de	document	:	{"_id" :	1	;	"marque" :	"Toyota",	"modele" :	"Prius+",	"immat" :	
"DH-040-VT",	"proprietaire" :	{"nom" :	"DYKSTEIN",	"prenom" :	"Eric",	"adresse" :	{ "voie"
:	"72,	rue	paradis" ,	"cp" :	"13006",	"ville" :	"Marseille" }	}	}
Montpelllier
Les	bases	de	données	de	type	Graphe
• Type	de	BDD	NOSQL	le	moins	répandu,	car	il	couvre	un	besoin	fonctionnel	très	particulier	
->	les	relations	multi-nœuds (type	réseau	social)
• Les	enregistrements	d’une	base	Graphe	sont	soit	de	des	« noeuds »	(ou	« nodes »),	soit	
des	« arcs »	(ou	« edges »)	qui	correspondent	aux	relations	entre	les	« noeuds »	.
• Les	nœuds correspondent	à	une	entité	de	données,		pouvant	contenir	des	données	ou	
des	tableaux	de	données	exclusivement	de	types	primitifs	(boolean,	number,	string),	
ayant	la	spécificité	d’être	reliable à	un	ou	plusieurs	autres	nœuds par	des	arcs.	
• Un	arc contient	les	données	permettant	de	relier	deux	noeuds :	un	« identifiant	de	
noeud »		de	départ,	un	« identifiant	de	noeud »	d’arrivée	et,	éventuellement,	des	
données	complémentaires	caractérisant	le	lien	entre	les	deux	nœuds.
• Le	système	de	requêtage n’est	pas	des	plus	simples	(pour	ce	que	j’ai	entrevu	de	Neo4j	:p)
En	théorie…
Montpelllier
Les	bases	de	données	de	type	Graphe
En	pratique… ->	Design	d’un	modèle	de	réseau	social
Relationnel
Personnes
Perso_id
Perso_nom
Perso_prenom
Relations
Perso_id_from
Perso_id_to
Relation_type
1 n
1
n
Problématiques d’interrogation de la base de
données pour retrouver le lien entre deux
personnes :
- Nombre de jointures compliqué à déterminer
pour trouver le parent/enfant le plus « éloigné » ou
le « chemin le plus court »
- Impossibilité de chercher dans deux directions
sans se casser la tête (ou faire exploser le SGBDR)
GrapheVS
Personnes
(noeud)
Perso_id
Perso_nom
Perso_prenom
Relations	
(arc)
_from
_to
type
Dans une base de type graphe, les personnes sont
enregistrés comme « nœuds » et les relations comme
« arcs ». Le moteur de graphe permet d’effectuer une
recherche mono ou bidirectionnelle sans la
« lourdeur » du SQL face à cette problématique
fonctionnelle. Il est possible de déterminer une
« profondeur » de recherche.
1 n
1
n
Montpelllier
Inconvénients	du	NOSQL
• Pas	de	structure	de	données	« in	database »	et	Zéro	contrôle	à	l’insertion	des	données,	
donc	:	
→ Il	faut	concevoir	une	« structure	logique »	de	vos	collections	de	données	et	coder	des	contrôles	
vous-même	avant	chaque	insertion	/	modification	pour	assurer	l’intégrité	du	type	de	données	à	
stocker (ce	que	vous	êtes	déjà	censés	faire,	ou	qu’un	framework fait	pour	vous	;D)
→ Les	modifications	manuelles	sont	à	éviter	pour	limiter	les	risques	de	bugs	dans	votre	application	
• Pas	de	système	de	clé	étrangère	pour	lier	les	collections	entre	elles,	cependant :
→ Possibilité	de	créer	des	arborescences	de	données	à	l’intérieur	d’un	enregistrement	dans	une	
base	de	type	Documents	->	inconvénient	sous-jacent	:	coder	de	manière	récursive	la	lecture	des	
données…
→ Possibilité	de	raccorder	des	« enregistrements »	entre	eux	avec	une	base	de	type		Graphe
→ Sinon,	relations	à	l’ancienne	(MyISAM style	pour	les	connaisseurs	;p)	->	indiquer	dans	un	champs	
d’un	document	ou	dans	une	colonne,	l’identifiant	du	document	ou	de	l’enregistrement	d’une	
autre	collection	/	table	lié	à	celui-ci.
Partie	1
Montpelllier
Inconvénients	du	NOSQL
• Mais	même	si	on	contourne	le	problème	de	l’absence	de	clés	étrangères…
→ Aucune	gestion	des	contraintes	d’intégrité	référentielle,	donc	il	va	aussi	falloir	les	coder	soi-
même	dans	son	applicatif	si	besoin.
→ Aucune	modification	ou	suppression	en	cascade	dans	le	cas	d’une	gestion	des	relation	via	
une	base	graphe	ou	bien	d’une	gestion	des	relations	à	« l’ancienne »	entre	deux	collections	/	
tables…
• En	conclusion :	Beaucoup	plus	souple,	plus	rapide,	mais	aussi	plus	de	
précautions	à	prendre	lors	de	la	manipulation	des	données	pour	
conserver	une	certaine	forme	de	cohérence	et	d’intégrité.	Sans	parler	de	la	
nécessité	de	coder	tout	ce	qui	a	attrait	aux	relations	entre	les	données	
lorsque	c’est	nécessaire.
Partie	2
Montpelllier
Des	questions	:)	?
Contact	info	:
Mail	:	eric@recrut-info.com /	e@riw.fr
Twitter	:	@edykstein
Merci	pour	votre	attention	^o^	!
Montpellier

Contenu connexe

Tendances

Big data: NoSQL comme solution
Big data: NoSQL comme solutionBig data: NoSQL comme solution
Big data: NoSQL comme solution
JEMLI Fathi
 
Java et les bases de données
Java et les bases de donnéesJava et les bases de données
Java et les bases de données
Guillaume Harry
 
Découverte de Redis
Découverte de RedisDécouverte de Redis
Découverte de Redis
JEMLI Fathi
 
Les modèles NoSQL
Les modèles NoSQLLes modèles NoSQL
Les modèles NoSQL
ebiznext
 
Paris JUG (sept 2010) - NoSQL : Des concepts à la réalité
Paris JUG (sept 2010) - NoSQL : Des concepts à la réalitéParis JUG (sept 2010) - NoSQL : Des concepts à la réalité
Paris JUG (sept 2010) - NoSQL : Des concepts à la réalité
Michaël Figuière
 

Tendances (20)

Big data: NoSQL comme solution
Big data: NoSQL comme solutionBig data: NoSQL comme solution
Big data: NoSQL comme solution
 
Mongo DB
Mongo DBMongo DB
Mongo DB
 
Bases de Données non relationnelles, NoSQL (Introduction) 1er cours
Bases de Données non relationnelles, NoSQL (Introduction) 1er coursBases de Données non relationnelles, NoSQL (Introduction) 1er cours
Bases de Données non relationnelles, NoSQL (Introduction) 1er cours
 
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
 
Java et les bases de données
Java et les bases de donnéesJava et les bases de données
Java et les bases de données
 
Base NoSql et Python
Base NoSql et PythonBase NoSql et Python
Base NoSql et Python
 
Découverte de Redis
Découverte de RedisDécouverte de Redis
Découverte de Redis
 
BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQL
 
Présentation de ElasticSearch / Digital apéro du 12/11/2014
Présentation de ElasticSearch / Digital apéro du 12/11/2014Présentation de ElasticSearch / Digital apéro du 12/11/2014
Présentation de ElasticSearch / Digital apéro du 12/11/2014
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQL
 
Introduction NoSql 201406 - lbroudoux
Introduction NoSql 201406 - lbroudouxIntroduction NoSql 201406 - lbroudoux
Introduction NoSql 201406 - lbroudoux
 
Découverte de Elastic search
Découverte de Elastic searchDécouverte de Elastic search
Découverte de Elastic search
 
Dojo 02 : Introduction au noSQL
Dojo 02 : Introduction au noSQLDojo 02 : Introduction au noSQL
Dojo 02 : Introduction au noSQL
 
Introduction aux bases de données NoSQL
Introduction aux bases de données NoSQLIntroduction aux bases de données NoSQL
Introduction aux bases de données NoSQL
 
Les modèles NoSQL
Les modèles NoSQLLes modèles NoSQL
Les modèles NoSQL
 
Chapitre 4 no sql
Chapitre 4 no sqlChapitre 4 no sql
Chapitre 4 no sql
 
NoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisationNoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisation
 
No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010
 
Migrer une application existante vers Elasticsearch - Nuxeo Tour 2014 - workshop
Migrer une application existante vers Elasticsearch - Nuxeo Tour 2014 - workshopMigrer une application existante vers Elasticsearch - Nuxeo Tour 2014 - workshop
Migrer une application existante vers Elasticsearch - Nuxeo Tour 2014 - workshop
 
Paris JUG (sept 2010) - NoSQL : Des concepts à la réalité
Paris JUG (sept 2010) - NoSQL : Des concepts à la réalitéParis JUG (sept 2010) - NoSQL : Des concepts à la réalité
Paris JUG (sept 2010) - NoSQL : Des concepts à la réalité
 

Similaire à NoSQL MeetUp

Similaire à NoSQL MeetUp (20)

BigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherBigData_Chp5: Putting it all together
BigData_Chp5: Putting it all together
 
cours06-nosql.pdf
cours06-nosql.pdfcours06-nosql.pdf
cours06-nosql.pdf
 
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTBenchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
 
MariaDB une base de donnees NewSQL
MariaDB une base de donnees NewSQLMariaDB une base de donnees NewSQL
MariaDB une base de donnees NewSQL
 
Serveur web / Base de donnees Langages de développement
Serveur web / Base de donnees Langages de développementServeur web / Base de donnees Langages de développement
Serveur web / Base de donnees Langages de développement
 
A Brief History of Database Management (SQL, NoSQL, NewSQL)
A Brief History of Database Management (SQL, NoSQL, NewSQL)A Brief History of Database Management (SQL, NoSQL, NewSQL)
A Brief History of Database Management (SQL, NoSQL, NewSQL)
 
Introduction à l'informatique documentaire
Introduction à l'informatique documentaireIntroduction à l'informatique documentaire
Introduction à l'informatique documentaire
 
BDRO.pdf
BDRO.pdfBDRO.pdf
BDRO.pdf
 
Database/ Bases de données
Database/ Bases de donnéesDatabase/ Bases de données
Database/ Bases de données
 
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETICNoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
 
Relational databases & NoSQL databases
Relational databases & NoSQL databasesRelational databases & NoSQL databases
Relational databases & NoSQL databases
 
Alphorm.com-Formation MongoDB Administration
Alphorm.com-Formation MongoDB AdministrationAlphorm.com-Formation MongoDB Administration
Alphorm.com-Formation MongoDB Administration
 
Les BD NoSQL
Les BD NoSQLLes BD NoSQL
Les BD NoSQL
 
Les bases de donnees nosql
Les bases de donnees nosqlLes bases de donnees nosql
Les bases de donnees nosql
 
Modèles de données et langages de description ouverts 5 - 2021-2022
Modèles de données et langages de description ouverts   5 - 2021-2022Modèles de données et langages de description ouverts   5 - 2021-2022
Modèles de données et langages de description ouverts 5 - 2021-2022
 
NoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler SofteamNoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler Softeam
 
Introduction aux bases de données
Introduction aux bases de donnéesIntroduction aux bases de données
Introduction aux bases de données
 
Bases de données no sql.pdf
Bases de données no sql.pdfBases de données no sql.pdf
Bases de données no sql.pdf
 
Introduction nosql
Introduction nosqlIntroduction nosql
Introduction nosql
 
Base de données
Base de donnéesBase de données
Base de données
 

NoSQL MeetUp

  • 3. Qu’est-ce que le NOSQL ? • Acronyme créé en 2009 : « Not Only SQL » -> il n’y a pas que le SQL dans la vie ;) ! • Moteurs de stockage de bases de données plus que « Systèmes de Gestion » : → Données stockées de manière non structurée (chaque « record » peut contenir des champs ≠ ) → Aucun contrôle sur l’intégrité des données (aucune règle d’écriture applicable -> les propriétés « cohérence » et/ou « isolation » du concept ACID ne sont généralement pas respectées) → Aucun système d’intégrité référentielle des données entre « entités » différentes. → Systèmes de requêtage des données plus ou moins élaborés • 4 familles / types de moteurs de stockage distincts : → Clés / valeurs (ex : Redis, DynamoDB, Voldemort) → Colonnes (ex : Cassandra, BigTables, Hbase) → Documents (ex : MongoDB, CouchDB, CouchBase) → Graphe (ex : Neo4j) Montpelllier
  • 5. Pourquoi le NOSQL ? • Pour répondre à des problématiques spécifiques de performance : → En cas de très grosse volumétrie de données → En cas de très grosses montées en charges (sites à fort trafic) vLes moteurs NOSQL sont plus rapides en lecture et en écriture qu’un SGBDR classique car ils n’effectuent aucun contrôle sur les données, la plupart peuvent charger leurs données en mémoire vive et/ou être répartis sur plusieurs serveurs en parallèle (sharding). • Pour répondre à des problématiques fonctionnelles spécifiques : → Designer une base de donnée pour développer un système de gestion du cache (modèle Clés / Valeurs) → Designer une base de données à la structure « super flexible » pour la réalisation d’un POC ou d’un MVP (modèles Documents et Colonnes) → Designer une base de données à nœuds multiples (type réseau social via le modèle Graphe) → Designer une base de données pour se lancer dans l’aventure « Big Data » <(-_-)> Montpelllier
  • 6. Les bases de données de type Clé / Valeur • Elles permettent un stockage de paires « clé / valeur » : la clé identifie l’enregistrement, la valeur étant la (ou les données) elle(s)-même(s) qui est/sont gérée(s) de manière « opaque » -> le type de donnée(s) est indéterminé et stocké généralement de manière binaire. • Elles offrent une large flexibilité concernant le type de donnée(s) à stocker : il peut s’agir d’une simple chaine de caractère, ou de tout autre type de données tel un objet JSON ou des données binaires (image, vidéo, exécutable, etc…). • Elles stockent les données en mémoire vive lorsqu’elles sont actives afin d’obtenir des temps de réponses très rapides. Montpelllier
  • 7. Les bases de données de type Colonnes • Type de BDD le plus proche des SGBDR en terme de structuration de données : Nous avons à faire à des lignes et des colonnes contenues dans des Tables -> Sauf que les colonnes sont créées pour chaque ligne et qu’elles ne sont pas décrites structurellement dans la définition de la Table. • Une colonne n’existe donc pas tant qu’une donnée n’a pas été enregistrée en base et la manière dont celles-ci sont stockées s’apparente à une paire « clé / valeur » où la clé est le nom de la colonne et la valeur est la donnée que l’on veut exploiter. • Ainsi, les données ne seront pas stockées par ligne mais par colonne -> Objectif pouvoir faire des traitements sur des colonnes spécifiques et non sur des lignes complètes pour un balayage des données par colonne plus rapide. Montpelllier
  • 8. Les bases de données de type Documents • Type de BDD NOSQL le plus populaire, notamment grâce à MongoDB • Stockage des données dans des collections de documents -> Par rapport aux bases de données relationnelles, les collections sont aux tables ce que les documents sont aux enregistrements. • Les données sont généralement formatées en JSON -> pratique à manipuler avec du JavaScript, d’où le célèbre couplage « NodeJS / MongoDB » • Possibilité de stocker tous types de données « primitives » dans une collection (boolean, number, string), mais aussi des tableaux de données ou des objets JSON contenant eux- mêmes des données de tous types -> possibilité de créer des arborescences de données complexes dans un document. • Exemple de document : {"_id" : 1 ; "marque" : "Toyota", "modele" : "Prius+", "immat" : "DH-040-VT", "proprietaire" : {"nom" : "DYKSTEIN", "prenom" : "Eric", "adresse" : { "voie" : "72, rue paradis" , "cp" : "13006", "ville" : "Marseille" } } } Montpelllier
  • 9. Les bases de données de type Graphe • Type de BDD NOSQL le moins répandu, car il couvre un besoin fonctionnel très particulier -> les relations multi-nœuds (type réseau social) • Les enregistrements d’une base Graphe sont soit de des « noeuds » (ou « nodes »), soit des « arcs » (ou « edges ») qui correspondent aux relations entre les « noeuds » . • Les nœuds correspondent à une entité de données, pouvant contenir des données ou des tableaux de données exclusivement de types primitifs (boolean, number, string), ayant la spécificité d’être reliable à un ou plusieurs autres nœuds par des arcs. • Un arc contient les données permettant de relier deux noeuds : un « identifiant de noeud » de départ, un « identifiant de noeud » d’arrivée et, éventuellement, des données complémentaires caractérisant le lien entre les deux nœuds. • Le système de requêtage n’est pas des plus simples (pour ce que j’ai entrevu de Neo4j :p) En théorie… Montpelllier
  • 10. Les bases de données de type Graphe En pratique… -> Design d’un modèle de réseau social Relationnel Personnes Perso_id Perso_nom Perso_prenom Relations Perso_id_from Perso_id_to Relation_type 1 n 1 n Problématiques d’interrogation de la base de données pour retrouver le lien entre deux personnes : - Nombre de jointures compliqué à déterminer pour trouver le parent/enfant le plus « éloigné » ou le « chemin le plus court » - Impossibilité de chercher dans deux directions sans se casser la tête (ou faire exploser le SGBDR) GrapheVS Personnes (noeud) Perso_id Perso_nom Perso_prenom Relations (arc) _from _to type Dans une base de type graphe, les personnes sont enregistrés comme « nœuds » et les relations comme « arcs ». Le moteur de graphe permet d’effectuer une recherche mono ou bidirectionnelle sans la « lourdeur » du SQL face à cette problématique fonctionnelle. Il est possible de déterminer une « profondeur » de recherche. 1 n 1 n Montpelllier
  • 11. Inconvénients du NOSQL • Pas de structure de données « in database » et Zéro contrôle à l’insertion des données, donc : → Il faut concevoir une « structure logique » de vos collections de données et coder des contrôles vous-même avant chaque insertion / modification pour assurer l’intégrité du type de données à stocker (ce que vous êtes déjà censés faire, ou qu’un framework fait pour vous ;D) → Les modifications manuelles sont à éviter pour limiter les risques de bugs dans votre application • Pas de système de clé étrangère pour lier les collections entre elles, cependant : → Possibilité de créer des arborescences de données à l’intérieur d’un enregistrement dans une base de type Documents -> inconvénient sous-jacent : coder de manière récursive la lecture des données… → Possibilité de raccorder des « enregistrements » entre eux avec une base de type Graphe → Sinon, relations à l’ancienne (MyISAM style pour les connaisseurs ;p) -> indiquer dans un champs d’un document ou dans une colonne, l’identifiant du document ou de l’enregistrement d’une autre collection / table lié à celui-ci. Partie 1 Montpelllier
  • 12. Inconvénients du NOSQL • Mais même si on contourne le problème de l’absence de clés étrangères… → Aucune gestion des contraintes d’intégrité référentielle, donc il va aussi falloir les coder soi- même dans son applicatif si besoin. → Aucune modification ou suppression en cascade dans le cas d’une gestion des relation via une base graphe ou bien d’une gestion des relations à « l’ancienne » entre deux collections / tables… • En conclusion : Beaucoup plus souple, plus rapide, mais aussi plus de précautions à prendre lors de la manipulation des données pour conserver une certaine forme de cohérence et d’intégrité. Sans parler de la nécessité de coder tout ce qui a attrait aux relations entre les données lorsque c’est nécessaire. Partie 2 Montpelllier