Discussion :

[nathieb]

Bonjour,

La question pourra être ressentie comme confuse, car je tente d'exploiter cette base, mais certaines notions me semblent confuse.
D'après la doc, on utilise des documents, qui peuvent être un assemblage de pluseiurs tables dans le monde "SQL", déjà je me dis comment je vais retrouver mes petits, mais la chose se complique car je n'est pas de notion de tables. Oui je sais, on est pas dans le même monde.
Mais imaginons, que je veuille stocker des stats,
les stats_produits
les stats_fournisseurs
les stats_établissements

avec des notions de tables de nomenclatures, histoire de liées mes dernières aux premières ( un bon schéma MCD ). comme la notion de table n'existe pas je me pose la question suivante, comment classer mes données ? des vues ???

Un éclairage ? une expérience ?

Merci à celle ou celui qui peut me guider.

olivier

[hugo123]

Je vais parler comme si c'était MongoDb puisqu'il s'agit de base documentaire et qu'une partie des concepts s'y retrouve.

Effectivement dans CouchDB ou MongoDB, on stocke des documents, donc en gros on obtient des choses comme ceci dans un cas simple :

produit : { ref_fabricant : "123", prixHT : 123}

La ou ca se complique, c'est quand on veut des relations entre objets. Par exemple entre un topic de forum et ces posts on pourra faire :

topic : { id : 1, title : "CouchDB et modélisation", posts : [
{content : "une question"},
{content : "une réponse"}
]}

Ici on a décidé d'embarquer un document (une liste pour être exacte) dans un autre document.
On profite aussi du fait que dans MongoDB, le document est la seule unité transactionnelle qui existe. On ne peut pas faire de transactions entre documents.

Mais la solution d'embarquer n'est pas toujours pertinente. Par exemple si on prend les auteurs dans notre exemple ci-dessus :

topic : { id : 1, title : "CouchDB et modélisation", posts : [
{content : "une question", authorId : 123 },
{content : "une réponse", authorId : 124}
]}

Si on avait mis l'auteur dans le document, on aurait eu une duplication très pénible à gérer dans les cas de modification des auteurs, cas fréquent sans doute dans un forum. C'était envisageable, mais pas forcément un bon choix (sans doute pas en fait).

Pour autant, des fois on acceptera de la duplication, par exemple si on place des tags sur un topic

topic : { id : 1, title : "CouchDB et modélisation",
tags : ["couchdb", "nosql"],
posts : [
{content : "une question", authorId : 123 },
{content : "une réponse", authorId : 124}
]}

Ici bien souvent, pour des tags ce sera acceptable de dupliquer l'info (sans doute que "couchdb" sera présent sur d'autres topic, il existe des solutions si on veut normaliser mais je ne m'étend pas la dessus (index de recherche).

Pour les stats, que ce soit MongoDB ou CouchDB, les deux sont armés pour fonctionner avec des jobs de MapReduce. CouchDB ne propose d'ailleurs que ce mode de requetage quand on veut chercher des données qui ne sont pas l'id. Un MapReduce sera parfaitement adapté pour du calcul de stats.
Sur MongoDB tu aurais aussi pu utiliser le framework d'aggrégation.

[nathieb]

Bonjour,

Merci pour ces précieuses infos. Sans abuser, si je comprends bien pour un document avec un lien (clef etréngère ) je peux me retrouver avec un document de taille impressionnante. Je parle de cela car je vais essayer d'utiliser des tables de faits ( modèle en étoile ) ?

Olivier

[hugo123]

je n'ai jamais tenté avec un modèle en étoile. Naivement je vois bien effectivement que tes documents vont avoir autant de sous document qu'il y a de relations dans ton étoile.
Je ne vois pas bien que ca va représenter en terme de volumétrie.
Saches que MongoDB limite la taille d'un document à 16Mb.

N'hésites pas à nous en parler après ton expérimentation.

[nathieb]

Bonjour,
En fait je stocke toutes les infos dans N documents, ou chaque document à tout en colone, très facile après de filtrer sur les paramètres ou les types.
J'évite les foreign ley ainsi.$
olivier

[hugo123]

ca mériterait un billet de blog

[nathieb]

Bonjour,

J'y songe car cela fait parti d'un sujet de mémoire. Je suis en train de récolter des infos.
J'avoue je suis en train d'essuyer touts les pb. Mais c'est formateur.

Mon plus gros souci, charger 1.2 millions de lignes d'oracle in one shot, avec une procédure PL/SQL récalcitrante .... tout une histoire. je suis en version 1.2 donc + pb de proxy CORS résolu.

Olivier