Discussion :

[abriotde]

La raison d'être du NoSQL est de créer des bases de données plus rapide que celle SQL en évitant certaines contraintes liés au SQL. Par exemple une base qui ne gère pas de droits d'accès et d'utilisateur gagne peu de temps mais cela peu parfois être utile. De même une base, NoSQL, qui n'a pas comme contrainte la jointure du SQL peut stocker / restituer plus rapidement les données. C'est le cas des bases clé/valeurs. Alors oui on gagne a utiliser du NoSQL si on a pas ces contraintes. Par contre remettre ces contraintes autre part, c'est perdre du temps, c'est réinventer la roue, c'est perdre en sécurité et efficacité (car on aura pas utilisé une méthode éprouvé)...
Une autre raison du NoSQL c'est de gérer de nouvelles contraintes comme celle des bases graphes. Cela permet de gérer la contrainte de jointure graphique et de résoudre des problème très simplement (Meilleur chemin par exemple) car la solution est intégrer dans la base.
Il y a des outils meilleurs que d'autres (MariaDB > MySQL > "SQL Server" ) mais il n'y a pas d'outils universel.

[Derf59]

Cassandra dispose d'un language de script (CQL) qui semble sympa.
Après si votre modèle de données est fortement lié sur les jointures et l'utilisation de rapport complexes, c'est sur que le NoSQL n'est peut être pas adapté.

[Traroth2]

Quand on besoin de gérer beaucoup de relations, une base de données relationnelle serait un meilleur choix qu'une base de données orientée document genre MongoDB ou qu'une base clé-valeur genre Cassandra ?

Sans déconner ???

De la même manière, je me suis rendu compte que j'arrivais vachement mieux à enfoncer des clous avec un marteau qu'avec une pelle à tarte ! Etonnant, non ?

[Gugelhupf]

Il faut aussi se dire que le SQL c'est 40 ans de travail, c'est un langage qui évolue constamment.

Je ne remet pas en cause JS/MongoDB, mais si je ne peux pas faire de jointure qui vont dans tous les sens pour récupérer des chiffres plus ou moins complexes, le NoSQL ne me sert à rien pour ma part.

[redcurve]

Il faut aussi se dire que le SQL c'est 40 ans de travail, c'est un langage qui évolue constamment.

Je ne remet pas en cause JS/MongoDB, mais si je ne peux pas faire de jointure qui vont dans tous les sens pour récupérer des chiffres plus ou moins complexes, le NoSQL ne me sert à rien pour ma part.

En tant que développeur je pense que ces bases vont se démocratiser mais pas forcément pour de bonnes raisons. Beaucoup sont très mal formés à la conception d'une base de données notamment via la méthode MERISE (on oublie UML qui est horrible pour ça).

En outre, beaucoup ne veulent pas apprendre et pense qu'il suffit d'utiliser des outils (comme si avoir une scie faisait de toi un charpentier ...), comme un ORM et que hop on glisse n'importe nawak dans le designer et voilà on a une base de données.

La quintessence du grand n'importe quoi concernant les bases de données c'est le code first, du coup on se retrouve avec des DB au schéma capilotracté , et après tu passes 4 jours à faire des scripts SQL pour modifier pratiquement tout le schéma de la db et créer des index etc. parce que des débiles croient en la magie. Mais à la fin du es content quand les perfs sont multipliés par 10 avec le même serveur sql.


Les bases NoSql sont bien mais pas quand tu as de l'information structuré (et encore ça dépend quoi), mais surtout l'absence de transaction de contrôle d'intégrité etc. n'est pas très rassurant. Dans le cas ou la perte de données est permise pourquoi pas, par exemple j'utilise Couchbase pour stocker des logs, si je perds quelques logs en cours de route ce n'est pas très grave.

La base de données "Nosql" que j'utilise le plus est Berkeleydb que j'ai wrapper dans des collections dotnet, du coup j'ai des collections du type :

Code :

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

1
2
3
4
DuplicatePersistentDictionary<TKey, TValue>
PersistentDictionary<TKey, TValue>
PersistentHashTable<TKey, TValue>
PersistentQueue<TValue>

Berkeley supporte les transactions ACID, la réplication, la mise en cluster etc. rien à voir avec les db key/value ayant le vent en poupe et dont l'implémentation est sacrément primitive à coté.

Je vais faire des

Code :

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

1
2
3
4
5
 
DistributedDuplicatePersistentDictionary<TKey, TValue>
DistributedPersistentDictionary<TKey, TValue>
DistributedPersistentHashTable<TKey, TValue>
DistributedPersistentQueue<TValue>

Mais ça c'est pour le fun.

[phili_b]

En outre, beaucoup ne veulent pas apprendre et pense qu'il suffit d'utiliser des outils (comme si avoir une scie faisait de toi un charpentier ...), comme un ORM et que hop on glisse n'importe nawak dans le designer et voilà on a une base de données.

C'est clair. En fait l'intérêt d'un ORM est d'avoir une couche d'abstraction commune à plusieurs moteurs de base de données en y standardisant les appels.

Mais le souci c'est qu'un certain nombre de développeurs pensent que ça leur permet de faire l'impasse sur la connaissance des bases de données et du SQL.

[pcaboche]

En tant que développeur je pense que ces bases vont se démocratiser mais pas forcément pour de bonnes raisons. Beaucoup sont très mal formés à la conception d'une base de données notamment via la méthode MERISE (on oublie UML qui est horrible pour ça).

En outre, beaucoup ne veulent pas apprendre et pense qu'il suffit d'utiliser des outils (comme si avoir une scie faisait de toi un charpentier ...), comme un ORM et que hop on glisse n'importe nawak dans le designer et voilà on a une base de données.

La quintessence du grand n'importe quoi concernant les bases de données c'est le code first, du coup on se retrouve avec des DB au schéma capilotracté , et après tu passes 4 jours à faire des scripts SQL pour modifier pratiquement tout le schéma de la db et créer des index etc. parce que des débiles croient en la magie. Mais à la fin du es content quand les perfs sont multipliés par 10 avec le même serveur sql.


Les bases NoSql sont bien mais pas quand tu as de l'information structuré (et encore ça dépend quoi), mais surtout l'absence de transaction de contrôle d'intégrité etc. n'est pas très rassurant. Dans le cas ou la perte de données est permise pourquoi pas, par exemple j'utilise Couchbase pour stocker des logs, si je perds quelques logs en cours de route ce n'est pas très grave.

C'est déprimant, tu viens de décrire exactement mon environnement de travail...

J'ai tous les ingrédients décrits plus haut :
- gens très mal formés à la conception d'une base de données
- ne veulent pas apprendre (pire : ils crachent sur le SQL)
- pensent qu'il suffit d'utiliser un ORM pour que ça marche
- problèmes de perfs
- on ne peut pas se permettre de perdre des données, et pourtant on utilise du NoSQL

Du coup, je trouve ton analyse extrêmement pertinente.

[landry161]

Cassandra dispose d'un language de script (CQL) qui semble sympa.
Après si votre modèle de données est fortement lié sur les jointures et l'utilisation de rapport complexes, c'est sur que le NoSQL n'est peut être pas adapté.

Ouais c'est juste.

[landry161]

Avec ma BD SQL Server ou MySQL
j ai ma table client comme suit
client
------------
id: 1
nom: Landry161
prenom: gary
telephone:+22500254423
------------
id: 2
nom: gary
prenom: flecther
telephone:+2250226523
Par contre avec le NoSQL j'ai ceci
client
----------
Avec le NoSQL pour ma table client j'ai ceci
Enregistrement1
id='jjfkvdjvnkvdkfvdfv'
nom:Landry161
prenom:gary
telephone:+22569854752
-----------

id='fdvdfvjdfvkd'
nom:kouame
prenom:serge
adresse:{Abidjan,Bouaké}
telephone:{"+2256652145","+22555652241"}
------------------
Bon voyez vous même.
NoSQL ou Base de données Relationnelles je crois que chacun a son domaine de prédilection.

[denis.flotat]

Trop de fragmentations dans les offres existante a part peut etre celles (Hadoop avec sa syntaxe proche de SQL) qui ont compris que ca ne sert a rien d'inventer une nouvelle syntaxe/langage (voir MongoDb ! clairement des langages de developpeur qui se font plaisir a inventer des syntaxes barbares et tres cabalistiques ... dont le degre de maintenabilité de code est proche de 0).
D'accord sur la plupart des avis par mon experience sur le sujet.
C'est encore du domaine de la recherche ces BDDs. Tout ce qui a ete supprimé pour des gains de perfs (contraintes intégrités, transactions etc.) commencent deja a etre annoncées dans les versions de certaines implémentations.
A mon avis c'est bon pour des applis d'entreprise (disposant de personnes a plein temps sur le sujet) mais impensable d'utiliser ceci pour un logiciel chez un client. Trop jeune, litterature pauvre et loin d'etre complete.

Le choix d'une Implementation est une voix de garage (pas possibilité de switcher sur une autre BDD sans tout reecrire !).
Oui pour un ciblage pour des applis type moteur de recherche mais sinon ...
Pour du BigData on voulait partir la dessus et finalement on est resté sur du Oracle et supprimant tout ce qui etait catalogué comme couteux par les modeles NoSQL.
Au moins on ne perd pas tout le temps passé a se former a ce SGBD. Les articles/livres sur le sujet sont souvent peu clairs sur les aspects outillages/admin/deploiement/maintenance etc.

[Traroth2]

Trop de fragmentations dans les offres existante a part peut etre celles (Hadoop avec sa syntaxe proche de SQL) qui ont compris que ca ne sert a rien d'inventer une nouvelle syntaxe/langage (voir MongoDb ! clairement des langages de developpeur qui se font plaisir a inventer des syntaxes barbares et tres cabalistiques ... dont le degre de maintenabilité de code est proche de 0).
D'accord sur la plupart des avis par mon experience sur le sujet.
C'est encore du domaine de la recherche ces BDDs. Tout ce qui a ete supprimé pour des gains de perfs (contraintes intégrités, transactions etc.) commencent deja a etre annoncées dans les versions de certaines implémentations.
A mon avis c'est bon pour des applis d'entreprise (disposant de personnes a plein temps sur le sujet) mais impensable d'utiliser ceci pour un logiciel chez un client. Trop jeune, litterature pauvre et loin d'etre complete.

Le choix d'une Implementation est une voix de garage (pas possibilité de switcher sur une autre BDD sans tout reecrire !).
Oui pour un ciblage pour des applis type moteur de recherche mais sinon ...
Pour du BigData on voulait partir la dessus et finalement on est resté sur du Oracle et supprimant tout ce qui etait catalogué comme couteux par les modeles NoSQL.
Au moins on ne perd pas tout le temps passé a se former a ce SGBD. Les articles/livres sur le sujet sont souvent peu clairs sur les aspects outillages/admin/deploiement/maintenance etc.

Avec MongoDB, on interagit avec la base à l'aide de fonctions Javascript. Le format d'échange, c'est du JSON. C'est tout à fait standard et ça n'a rien de cabalistique.

[polkduran]

A mon avis Matt n'a pas fait le bon choix dès le début en prennant du NoSQL et il rectifie juste son mauvais choix en passant à du relationnel.
Comme beaucoup il est tombé dans le piège de l'effet de mode sans savoir dans quels cas il convient d'implémenter du bon vieux relationnel ou du NoSQL.
NoSQL n'a pas vocation à remplacer le relationnel mais à proposer une solution pour des cas où le relationnel convient moins.

[JSLover]

Comme beaucoup de développeurs j'ai commencé mes experiences avec les BDs avec les bases de données relationnelles : MySQL, MS SQL Server et 4D, mais durant les deux dernière années j'ai découvert les bases de données NoSQL est plus précisement WakandaDB et MongoDB, vu que j'ai passé du developpement Desktop au developpement web 2.0 qui necessite l'utilisation des base de données NoSQL, et c'est le cas pour Facebook, Twitter, ...

Je pense que le cas de Matt est différent de mon cas, vu qu'il developpe des solutions pour gérer les equipement de foyer (internet of things), son choix peut etre justifier dans ce cas, mais pour des applications web qui necessite un tres grand nombre d'enregistrement et des recherches rapides sur ces enregistrements, le NoSQL est le meilleur choix en terme de performance et de simpliciter d'utilisation, si tu a deja developper avec JavaScript, tu peux créer tes requete NoSQL comme si tu developpe une application dans le meme code et avec un syntaxe simplifié ...


**NOSQL est le meilleur choix pour les applications web 2.0**

[pcaboche]

**NOSQL est le meilleur choix pour les applications web 2.0**

Désolé, mais ici on ne fait pas d'affirmation péremptoire du genre "la solution X est le meilleur choix pour les applications Y".

Il faut justifier et nuancer, car cela dépend souvent des cas.

Si l'application :
- a énormément d'enregistrements
- qu'on veut des résultats rapidement
MAIS :
- on n'a pas besoin de connaitre le nombre exact d'enregistrements correspondant, une approximation nous suffit (ex: "environ 5 millions") et s'il manque un enregistrement c'est pas dramatique (ex : "il manque mon tweet de Noël 2009")
ALORS
-> le NoSQL se justifie.

En revanche, si l'application :
- a besoin de connaitre le nombre exact d'enregistrements correspondant (ex: l'ensemble des transactions effectuées) et l'absence d'un enregistrement a des conséquences dramatiques le résultat final (ex : le solde du compte n'est pas le bon)
- que le modèle est très clairement relationnel (ex: on doit mettre en relation des transactions liées à l'achat avec des transactions liées à la vente)
MAIS :
- on accepte certaines limitations en termes de volums et de rapidité, et on utilise certaines techniques pour pallier au problème (ex : indexation, partitionnement, dénormalisation, datawarehousing...)
- on dispose d'un langage puissant pour effectuer de nombreuses opérations dans la base (SQL)
ALORS
-> on utilise du SQL

Le problème, c'est que certains utilisent une technologie alors que c'est l'autre qui se justifie (ex : du NoSQL pour des modèles très clairement relationnels), et le plus souvent pour de très mauvaises raisons (ex : "j'aime pas le SQL... Je veux faire du Javascript partout : côté client, serveur et BDD...").

[JSLover]

Pierre,

Ce n'était pas une affirmation; mais un retour d'expérience et un point de vue personnelle, les bases de données NoSQL se justifie par les grands CRM, ERP et Applications web 2.0 qui les utilisent, les grandes firmes du web ont opté pour le NoSQL vu les performances et les avantages (stockage basé clé-valeur, sclation, fast, JSON, ...etc.)Qui l'offre par rapport au RDBMS ...

Je pense que si on peut établir une liste de critères sur laquelle les développeurs pourront se basé pour faire le choix entre NoSQl ou RDBMS, cette discussion sera bénéfique au lecteurs, au lieu que chacun défond son choix !

[pcaboche]

Ce n'était pas une affirmation; mais un retour d'expérience et un point de vue personnelle

C'était une remarque sur la forme, et non pas sur le fond.

Apparement c'est ton premier message (au passage, bienvenue ! ) et il y a quelques principes à respecter.

Par exemple, on évite les affirmations trop directes du genre "**la solution X est la meilleure**" car c'est beaucoup trop partisan.

les grandes firmes du web ont opté pour le NoSQL vu les performances et les avantages (stockage basé clé-valeur, sclation, fast, JSON, ...etc.) qu'il l'offre par rapport au RDBMS ...

L'argument classique : "NoSQL c'est bien, la preuve : Facebook, Twitter et cie l'utilisent".

Le problème, c'est qu'on n'a pas forcément les mêmes besoins que Facebook et Twitter...

Un billet intéressant : https://blogs.law.harvard.edu/acts/2...relational-db/
Le point que je trouve intéressant dans ce billet concerne les jointures (et par extension les groupements et le reporting) :

The big thing you lose with noSQL is joins. If you’re not doing joins noSQL will probably outperform a relational db. So if you don’t need reporting, if there’s no complexity needed for the data, noSQL is actually a fine solution. That’s not to say you can’t do joins. They’re just different and much slower to perform.

Et justement, j'ai besoin de faire beaucoup de jointures et de reporting...

Je pense que si on peut établir une liste de critères sur laquelle les développeurs pourront se baser pour faire le choix entre NoSQl ou RDBMS, cette discussion sera bénéfique au lecteurs

C'est un peu ce que j'ai fait dans mon poste précédent, non ?

Maintenant on peut ajouter les jointures et groupements à la liste des critères.

Quoi d'autre ?

[JSLover]

Il y'a des méllliers d'article comme celle que tu as mentionné, voila un http://www.infoworld.com/article/261...evolution.html (tu peux trouver d'autres articles en bas )

Pour les jointures cela est connu, pourtant tous les solutions NoSQL présentent des solutions pour cette partie, d'autre part les meilleures outils de reporting se base sur le web : HTML5, JavaScript, vu l'intéractivité et la rapidité du web par rapport aux apps desktop ..., il y a aussi des solutions pour les transactions, les

Je te propose de tester : WakandaDB avec Wakanda Studio, MongoDB/Cassandra/couchDB ... avec NodeJS et webstorm !

Malheureusement, on peut pas trouver des benchmarks fiables entre les deux ...etc, chacun peut exprimer son point de vue, mais par l'expérience qu'on peut confirmer ...

Merci,

[landry161]

Les avis sont vraiment partagés à ce que je vois

[pcaboche]

Les avis sont vraiment partagés à ce que je vois

Au contraire, on est tous d'accord pour dire : "ma solution est la meilleure, la vôtre elle est nulle"...

[landry161]

Pour Matt, elles ne prennent pas correctement en charge les relations. Or, les données sur lesquelles ils sont amenés à travailler sont fortement relationnelles.

Normal.

La seconde observation de Matt, c’est que l’écriture de la syntaxe pour le retrait d’information dans la base de données non relationnelle peut s’avérer complexe