Le noSQL, c'est bien quand on a peu de très grandes tables. Dans la situation inverse (ce qui est souvent le cas dès qu'on fait de la gestion), on se retrouve très vite coincé par l'absence de jointures entre tables. On est alors obligé de dénormaliser les tables, c'est-à-dire rajouter des informations que l'on pourrait obtenir autrement, ce qui augmente la taille des tables, et donc l'espace mémoire/disque, inutilement. Sans parler des difficultés accrues à modifier les informations, modéliser des associations many-to-many ou non-binaires, etc.
C'est aussi se passer des nombreuses fonctionnalités de SQL difficiles à transposer avec juste des opérations fonctionnelles : requêtes imbriquées, triggers, contraintes, intégrité…
En ce qui concerne les calculs sur de grands volumes de données, je sais que le MapReduce est très puissant, mais je le trouve beaucoup moins intuitif qu'un GROUP BY en SQL.
En ce qui concerne les risques d'injection SQL, c'est surtout dû à une très mauvaise pratique de personnes n'ayant jamais été réellement formées au SQL, ou s'étant arrêté à la deuxième page du tuto du site du Zéro. Il y a des myriades d'outils (requêtes préparées, protection des chaines…) pour s'en prémunir, avec une règle simple : ne jamais passer directement une information issu du GET/POST/COOKIE… directement dans une requête SQL par concaténation.
# Jointures et bases complexes
Posté par scand1sk (site web personnel) . En réponse au journal Témoignage d'expérience de nosql avec PHP et Mongodb. Évalué à 8. Dernière modification le 22 octobre 2012 à 11:00.
Le noSQL, c'est bien quand on a peu de très grandes tables. Dans la situation inverse (ce qui est souvent le cas dès qu'on fait de la gestion), on se retrouve très vite coincé par l'absence de jointures entre tables. On est alors obligé de dénormaliser les tables, c'est-à-dire rajouter des informations que l'on pourrait obtenir autrement, ce qui augmente la taille des tables, et donc l'espace mémoire/disque, inutilement. Sans parler des difficultés accrues à modifier les informations, modéliser des associations many-to-many ou non-binaires, etc.
C'est aussi se passer des nombreuses fonctionnalités de SQL difficiles à transposer avec juste des opérations fonctionnelles : requêtes imbriquées, triggers, contraintes, intégrité…
En ce qui concerne les calculs sur de grands volumes de données, je sais que le MapReduce est très puissant, mais je le trouve beaucoup moins intuitif qu'un GROUP BY en SQL.
En ce qui concerne les risques d'injection SQL, c'est surtout dû à une très mauvaise pratique de personnes n'ayant jamais été réellement formées au SQL, ou s'étant arrêté à la deuxième page du tuto du site du Zéro. Il y a des myriades d'outils (requêtes préparées, protection des chaines…) pour s'en prémunir, avec une règle simple : ne jamais passer directement une information issu du GET/POST/COOKIE… directement dans une requête SQL par concaténation.