C'est le fin mot de l'histoire :)

[quote="zeus"]Pour moi, le NoSQL est intéressant lorsque l'on quitte la notion d'ACID, et que l'on veut une base permettant de stocker de gros volumes de données volatile (j'entends par la des données dont la présence n'est pas nécessaire à la cohérence du reste du schéma.

Pour vous donner un exemple, il y a peu, je travaillais sur un site d'enchère pour lequel il me faut stocker l'intégralité des propositions des enchérisseurs.
Ma problématique était que dans un schéma relationnel standard respectant les formes normales, tout calcul sur un enchère aurait nécessité de tenir compte de l'intégralité des données de ma table de propositions, qui contient des milliers, voir des dizaines de milliers d'enregistrement pour chaque enchère.

Donc, partant de ce postulat (gros volume de données, table en mutation constante, nécessité de casser certaines formes normales pour optimiser le fonctionnement), j'en suis arrivé à la conclusion que ma table de proposition était toute vouée à s'appuyer sur un système NoSQL.

Au final, j'ai un schéma relationnel standard contenant la principale partie de mes données, celles qui sont structurantes pour mon application, et j'utilise MongoDB pour stocker ma table volatile. Et j'utilise cette table volatile pour mettre à jour mon schéma principal avec des résultats de calcul.

Du coup, et pour reprendre ce qui a été dis plus haut : SGBD vs NoSQL est du type PHP vs C++, à savoir qu'ils ne sont pas concurrent, que l'un n'est pas meilleur que l'autre, juste que ce sont des outils distincts qui ont des utilités différentes, et que, comme d'habitude, il faut commencer à se demander ce que l'on veut faire avant de choisir l'outil qui convient[/quote]

Pour moi, le NoSQL est intéressant lorsque l'on quitte la notion d'ACID, et que l'on veut une base permettant de stocker de gros volumes de données volatile (j'entends par la des données dont la présence n'est pas nécessaire à la cohérence du reste du schéma.

Pour vous donner un exemple, il y a peu, je travaillais sur un site d'enchère pour lequel il me faut stocker l'intégralité des propositions des enchérisseurs.
Ma problématique était que dans un schéma relationnel standard respectant les formes normales, tout calcul sur un enchère aurait nécessité de tenir compte de l'intégralité des données de ma table de propositions, qui contient des milliers, voir des dizaines de milliers d'enregistrement pour chaque enchère.

Donc, partant de ce postulat (gros volume de données, table en mutation constante, nécessité de casser certaines formes normales pour optimiser le fonctionnement), j'en suis arrivé à la conclusion que ma table de proposition était toute vouée à s'appuyer sur un système NoSQL.

Au final, j'ai un schéma relationnel standard contenant la principale partie de mes données, celles qui sont structurantes pour mon application, et j'utilise MongoDB pour stocker ma table volatile. Et j'utilise cette table volatile pour mettre à jour mon schéma principal avec des résultats de calcul.

Du coup, et pour reprendre ce qui a été dis plus haut : SGBD vs NoSQL est du type PHP vs C++, à savoir qu'ils ne sont pas concurrent, que l'un n'est pas meilleur que l'autre, juste que ce sont des outils distincts qui ont des utilités différentes, et que, comme d'habitude, il faut commencer à se demander ce que l'on veut faire avant de choisir l'outil qui convient

Super ,

merci pour vos réponses et points de vues sur ces techno , content que ce sujet ne parte pas en troll d'ailleurs pour tout nouveau "participant" à ce thread :)

[b]Note:[/b][i]Attention , histoire de ne pas dériver vers un troll , suite à mes points de vues ci-dessous , ce poste est uniquement là pour recueillir des points de vues sur les différentes techno , ( avantages , inconvénients , cas d'utilisations , retour d'expérience ) et non pour dire que l'un est meilleur que l'autre ce qui serai absurde à mon sens , merci à vous pour votre participation. [/i] :D

J'ai bien compris la différence concernant la garantie de la cohérence des données entre tables .

Pour ce qui est de la suppression ( exemple de devlop78 avec les devis et piéces jointes ) , je part du principe ou tout document enregistré en base .. ne doit pas être supprimé pour ma part , je ne fait donc que très rarement des "DELETE" ( sauf petites tables dont les données sont là uniquement pour le bon fonctionnement de l'application ( session , sérialisation , etc , etc .. ) ).

En fait ce qui me séduit avec le NoSql , c'est justement le coté "sans schéma" ( attention , sans schéma ne veut pas dire sans réflexion du/des développeurs ).
Prenons l'exemple suivant :

Une société fait de la production sur mesure , chaque produit possède donc son lot de paramètres ( dans mon cas il y en avait au maximum un bon 200 ) ..
Il était donc impossible d'enregistrer ses paramètres en base de manière simple , j'ai donc due passer par l'utilisation de fichiers xml qui regroupent ces paramètres , j'ai trouvé dommage car celà implique du développement en plus , de la gestion de fichier / de stockage backup ect ... certes rien d'insurmontable mais qui au final engendre des pertes de temps de développement et de performances dues aux lectures/recherches/écritures sur ces fichiers

C'est donc là que le NoSql à l'époque m'aurait grandement simplifié la tâche et augmenté les perfs de mon appli .

Autre point séduisant , pas besoin d'être DBA pour gérer et administrer un serveur Nosql .. l'administration est extrêmement simple , en cas de manque de performances , il est tres rapide d'ajouter une machine supplémentaire ( extension horizontal ) , la répartition de charge et la fragmentation des données se fait automatiquement ... ( j'ai fait de la réplication sous mysql entres plusieurs serveurs .. je peux vous garantir que ce n'est pas la même paire de manche .. ( surtout quand c'est la première fois :) ) ).

A mon avis une utilisation typique est une gestion de documents dont les méta données ne sont pas connu au moment de la création de base : je pense que dans ce cas, le fait que le NOSQL n'est pas de schéma formel l'emporte sur une base relationnelle. Surtout que la recherche dans les méta données sera très simplifié.

Mais, bon, j'ai pas encore eu le besoin...

J'ai lu la première partie de http://www.developpez.net/forums/d905036/club-professionnels-informatique/actualites/developpeurs-offrent-methode-dutilisation-nosql-cette-technologie-must-mode/

[quote]bases de données fondées sur des documents ou les bases de données sans schéma[/quote]

Rien que ça, ça me fait froid dans le dos.

ou

[quote]Saviez-vous que Cassandra nécessite un redémarrage lorsque vous modifiez la définition d'une colonne dans une table ?[/quote]

Moins "froid dans le dos", puisque la modification du schéma de la SGBDR n'est pas censé s'effectuer souvent si dès le départ la modélisation a été bien faite. De plus, certains SGBDR, comme celui de Microsoft, si je ne me trompe pas, ne le permet tout simplement pas.

Un exemple déjà tout bête est une application rapidement conçue pour mon entreprise. Il s'agit de suivi de devis. Pour partir sur la modélisation (si je puis dire), il y a une table avec les demandes de devis, une table avec les réponses, une table avec les pièces jointes (le nom des fichiers), et des fichiers dans un dossier. Dès le départ, toutes ces tables sont liées (j'ai opté pour un RESTRICT pour ma part, et je vais m'expliquer). Il n'est alors pas possible de supprimer un devis qui possède des réponses, pas possible de supprimer une réponse qui possède des pièces jointes, mais MALHEUREUSEMENT, tout à fait possible de supprimer une ligne de pièce jointe sans supprimer le fichier auquel elle fait référence. Et c'est bien là dessus que j'avais réfléchi à stocker mes fichiers sans la base. Sans cela, un petit CASCADE aurait été merveilleux, et la cohérence assurée (elle l'est actuellement, mais nécessite l'intervention d'un langage tel que PHP, avec plusieurs requêtes, pour faire ce que le SGBDR devrait faire tout seul en une ligne SQL, bien que l'on puisse la réduire en une seule avec appel d'une fonction ou procédure + suppression du fichier par le langage PHP).

Peut-on m'expliquer comment cette abstraction et cette délégation de responsabilité serait possible avec une base de données non relationnelle ? Si les fichiers étaient stockées côté SGBDR, il aurait été très facile de développer l'application en 50 langages différents, et ce très facilement.

D'un autre côté, même si la critique de NoSQL du lien ne va pas en sa faveur, il doit bien y avoir des avantages pour certaines utilisations.

[quote="stopher"]Atomicity (atomicité), Consistency (cohérence), Isolation, Durability (durabilité).

Les axes principaux du NoSQL: haute disponibilité et partitionnement des données, au détriment de la consistance.

Effectivement pas conseillé pour les bases tres sensibles qui se doivent d'avoir que des données valides , mais restons au niveau de la majeur partie des appli web ...
Je serais curieux de voir combien de sites web plus ou moins gros ( hors transaction bancaire ) utilisent les transactions pour leurs requêtes ....

C'est justement cette limite que j'ai du mal à cerner .. quand peut-on utiliser du Nosql ou des DDB standard relationnel , et quand est-il déconseillé d'utiliser des bases nosql ou des moteurs ne supportant pas les transactions ....

Je trouve ce point assez flou ..[/quote]

On pourrait se poser la même question concernant les bases de données objet. Je ne connais pas suffisamment les SGBD(x) pour dire lequel utiliser dans quelle situation. Je ne connaissais pas NoSQL, personnellement. Concernant l'utilisations des transations, ce n'est pas la seule fonctionnalités des SGBDR, ni le seul critère de l'ACID, loin de là. La transaction assure, en gros, entièrement l'atomicité et l'isolation, mais n'est qu'un composant de la cohérence. Concernant la durabilité, il s'agit pour moi d'un critère commun à tout système de gestion de données, contrairement aux variables, sessions, etc.

Revenons sur les transactions ... la majeure partie des applications web développées par les gens n'utilisent même pas le relationnel des SGBDR, ni les transactions, et ce ne sont pas des références en matière d'ACID. Il est vrai qu'entre la vérification de présence d'un utilisateur dans une table, et l'insertion de cet utilisateur si inexistant, le risque que le même utilisateur soit rajouté entre ces deux requêtes SQL est si proche de 0 qu'il est fort possible qu'un développeur qui ne le prévoit pas n'aura jamais ce problème. Ce n'est pourtant pas une raison. Il en est de même pour la modification (update) de deux tables différentes : après débogage, quels sont les risques que le deuxième update échoue alors que le premier a réussi ? Très proche de 0 aussi. Et pourtant, dans la théorie, ce risque existe, et ferait perdre toute cohérence à la base de données, sans parler des conséquences. Et concernant la cohérence, il faut noter aussi toutes les contraintes que proposent les bons SGBDR, comme les contraintes d'unicité, les contraintes de validation, voire les assertions et les triggers. Ainsi, l'ajout d'un utilisateur peut se permettre de se passer d'une vérification au préalable grâce à cette contrainte, bien que la gestion de l'erreur retourné par le SGBDR en sera plus compliqué : la cohérence sera, elle, assurée.

Bref, NoSQL, je ne connais pas. Mais je doute que si il a été inventé en 2009, ce n'est pas parce que ses inventeurs s'ennuyaient, mais bien pour répondre à des problématiques auxquels ni MySQL, ni PostgreSQL, ni Oracle (pour ne citer qu'eux) ne répondaient. Personnellement, je me destine à des applications de gestion ou de même type, et les SGBDR sont pour moi le meilleur outil à cela. Peut-être qu'une vision plus concrète de NoSQL, que la simple description que j'ai pu voir sur Wikipedia, pourrait nous montrer l'avantage dans certaines situations, et surtout lesquelles, de ce SGBD. Et il est tout à fait possible qu'il soit complémentaire, tout comme (parait-il, mais je n'ai pas encore assez de recul), PostgreSQL est un SGBDR et SGBDO à la fois. On peut imaginer qu'ils ne s'agissent pas de concurrence de type, mais bien de spécificités, fonctionnalités, comportement ... un peu comme un langage objet peut être aussi procédural, mais surtout peut être évenementiel ou non : on peut rarement mettre un seul nom à un système.

J'attends la suite pour en savoir plus :p

Atomicity (atomicité), Consistency (cohérence), Isolation, Durability (durabilité).

Les axes principaux du NoSQL: haute disponibilité et partitionnement des données, au détriment de la consistance.

Effectivement pas conseillé pour les bases tres sensibles qui se doivent d'avoir que des données valides , mais restons au niveau de la majeur partie des appli web ...
Je serais curieux de voir combien de sites web plus ou moins gros ( hors transaction bancaire ) utilisent les transactions pour leurs requêtes ....

C'est justement cette limite que j'ai du mal à cerner .. quand peut-on utiliser du Nosql ou des DDB standard relationnel , et quand est-il déconseillé d'utiliser des bases nosql ou des moteurs ne supportant pas les transactions ....

Je trouve ce point assez flou ..

Travaillant sur des bases dans une orientation ACID, je pense surtout qu'il s'agit de réponse à des besoins différents.

A vrai dire , l'un ou l'autre d'apres mes recherches sont largement capables de subvenir à mes besoins ...

Je suis particulièrement intéressé par mongoDB pour sa simplicité d'administration et de "scalabilité" ( j'ai donc commencé mes développement dans ce sens ).

Car j'aime toucher des nouvelles techno ..

Mais quelqu'un a t'il déjà mis en prod un produit avec ce genre de techno ?

Tout dépend du but poursuivi ;)

Si tes données s'adaptent au DB relationnelles, c'est le chemin à suivre.

Sinon, si tu penses qu'elles sont mieux adaptées au NoSQL (je pense surtout à du Big Data, map&reduce, etc..), alors le NoSQL est le chemin à suivre.

bonsoir à tous ,

j'aimerais avoir des retours sur l'utilisation de base nosql tel que mongodb

bien
pas bien
bonne et mauvaise exp.

merci d'avance pour votre participation :)

bonne soirée ,
ch