Discussion :

[karamovic]

Bonjour;

J'ai lu un article à propos de google App Engine, j'ai constaté que ce dernier offre la possibilité de créer des bases de données et des applications web basées sur les serveurs de Google.
Le SGBD offert par google App Engine n'est plus fondé sur l'architecture classique des bases relationnelles , mais en NOSQL.
Ensuite j'ai effectué des recherches sur le NOSQL, et j'ai trouvé que les données dans cette catégorie de SGBD ne sont pas manipulées avec SQL et ne sont pas stockées dans des tables :o.
- la 1er question qui m'arrive: comment les données sont stockées dans le NOSQL?
- si on a plusieurs entités( par exemple table produits, clients, catégorie...) comment effectuer la relation entre ces tables en cas de suppression, modification... ?
merci d’avance cher Developpez.com

[hugo123]

Ouch, question très très vaste
Désolé mais la réponse ne pourra couvrir tout. Je vais essayer de synthétiser.

Il y a plus de 150 bases classé comme Nosql, sans parler des bases de données Objet, XML etc...

http://nosql-database.org/

La plupart ont fait des choix différents en terme de stockage et en terme de fonctionnalités.
On peut trouver 4 grandes familles, les clés valeurs, les orientées documents, les graphes, les orientées colonnes.
Il faut bien regarder ses cas d'usage avant de se lancer.

Le datastore de GAE est décrit ici : https://developers.google.com/appeng...hon/datastore/

a+

[karamovic]

merci Hugo pour ta réponse.
Pour que je puisse détecter la différence que je cherche, je propose un petit exemple.
Supposant qu'on a 2 tables, table client( numClient, nom, ville), et table compte( numCompte, ...., numClient, solde).
Par une requête SQL(jointure), Dans une application on peut faire tout simplement la relation entre client et son compte.
Nn NOSQL, comment ça se passe les choses, si on utilise jamais les relations/requête SQL? et comment les données logiques sont ils stocker, si le NOSQL n'utilise pas les tables?
Merci encor une fois

[p3ga5e]

Dans MongoDB , qui est une base de données orienté document, les données logique sont stocké dans un format BSON qui est une sérialisation binaire d’objets JSON.

Donc, en gros, un document, dans MongoDB, est un objet JSON, avec ton exemple de clients et de comptes pas besoin de jointure, cela peut être modélisé directement dans l’objet client, comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
{ 	Nom : 'karamovic',
	Ville : "Paris",
	Comptes : [
		{ 	libelle : "Compte courant",
			numCompte : "IBANXXXXXXXXXXXXXXXXX",
		        solde : -200
		},
		{	libelle : "livret A",
			numCompte : "IBANXXXXXXXXXXXXXXXXX",
		        solde : 4
		}
	]
}

[hugo123]

En fait, quand tu énonces ton problème, tu remarqueras que tu viens de partir d'une représentation relationnelle de tes données : 2 entités avec des attributs et une relation entre les deux.
En fait tu as modélisé tes données selon une méthode donné.
Or avec une base Nosql, il y a un nouveau effort de modélisation.
Par exemple avec la réponse de p3ga5e la modélisation proposé est de regrouper l'ensemble des entités dans le même document (l'unité de persistence dans MongoDB).
Si c'était une base graphe, tu aurais pu avoir deux entités et une relation entre les deux. Les "jointures" sont possibles avec une base graphe.
Bref, c'est pour ca qu'il faut bien étudier chaque type de base, les modélisations possibles et l'adéquation avec tes cas d'usages.
Chaque type de base n'est pas interchangeable.

[karamovic]

merci beaucoup p3ga5e et Hugo123 pour vos réponses.