Developpez.com

Le Club des Développeurs et IT Pro

SQL Vs NoSQL, quel est votre préféré ?

Participez au sondage et au débat puis donnez-nous vos avis

Le 2015-08-28 15:15:43, par Francis Walter, Expert éminent sénior
SQL Vs NoSQL, quel est votre préféré ?
Participez au sondage et au débat puis donnez-nous vos avis

Il y a 10 ans de cela, la majorité des développeurs et entreprises (environ 60%) méconnaissaient encore le NoSQL (Not only SQL). Le langage SQL (Structured Query Langage) était le langage de définition et de manipulation de données utilisé par tous et, dans le temps, ce langage pouvait largement répondre et satisfaire aux besoins de la grande majorité des entreprises à l'exception des plus grandes connues sous les noms Facebook, Google, Twitter, Amazon, eBay, etc.

En effet, avec l'évolution du numérique, les quantités de données à gérer ne cessent d'augmenter de façon exponentielle surtout chez les géants d'Internet avec une forte audience. La gestion de ces données avec des SGBD relationnels était devenue très complexe contrairement au NoSQL qui, avec une scalabilié accrue, offre une bonne performance malgré le très gros volume des données. La manipulation des données est plus simple que le SQL classique qu'on manipulait. On parle désormais de tableaux associatifs Clé/Valeur.


Le NoSQL s'est véritablement répandu après le meetup NoSQL qui a eu lieu le 11 juin 2009 à San Francisco. Même si la technologie est idéalement faite pour les entreprises avec une très grande audience sur Internet telles que Google, LinkedIn... de nombreux développeurs (web et mobile en particulier) et entreprises y trouvent tout leur intérêt en raison des coûts onéreux qu'impliquent des SGBD relationnels tels que Oracle, SQL Serveur, etc. C'est d'ailleurs l'une des raisons pour lesquelles le langage JavaScript connait un réel essor.

Cependant, pour une raison ou une autre, certains préfèrent et ne jurent que par le SQL avec des bases de données relationnelles. Cela peut être par habitude ou à cause de ce que cela couterait de faire une migration vers une base de données non relationnelle ou la politique d'entreprise ou autres. Alors, dites-nous :
Quel type de SGBD utilisez-vous ? NoSQL ou relationnel ?
Pour quelles raisons l'utilisez-vous ?
Avez-vous déjà eu à essayer l'autre ? Quelle est votre impression ?

Liens :
Forum SQL
Forum NoSQL
Tutoriels NoSQL
La Rubrique NoSQL
  Discussion forum
42 commentaires
  • solstyce39
    Membre confirmé
    Aucun des 2 je les considère plus comme 2 technologies complémentaires répondant à des besoins différents plutôt que de réel concurrent
    le 28/08/2015 à 15:52
  • Gugelhupf
    Modérateur
    Les 2 ne sont pas comparables, le NoSQL n'est même pas comparable à lui-même car il existe plusieurs catégories de NoSQL (clé/valeur, colonne, document, graph).

    Pour le NoSQL, je dirais que le manque :
    • des requêtes complexe avec une syntaxe basique
    • des fonctions d'agrégation
    • des jointures
    • des transactions entre table (ou "document"
    • des contraintes d'intégrité
    • d'une norme ANSI/ISO

    fait que je préfère le SQL.

    Mais je ne nie pas que l'implémentation du distribué dans ces technologies récentes est très très intéressante.
    le 28/08/2015 à 16:51
  • SQLpro
    Rédacteur
    Effectivement NoSQL et SQL (en faite on devrait dire bases de données relationnelles car on peut faire du SQL sur n'importe quel format de données : texte, tableur...) sont des technologies différentes.

    Comme déjà dit le NoSQL ne couvre pas une technologie, mais une "mode", une "vague" regroupant différentes technologies (graphe, document, paires clef/valeur...).

    Le relationnel est à préférer dans le cas de l'informatique de gestion, nécessitant à la fois des contraintes complexes (clef étrangères, validation des données, unicité sémantique...), les transactions et bien entendu un modèle de données bien fait (structuration des données)
    Le NoSQL est à préférer pour le "text-mining" dans des documents déstructurés dont les composantes de base sont la date et l'origine géographique.

    En fait la technologie sous-jacente intéressante n'est pas le NoSQL, mais bien le big data et donc des algorithmes tel que Map/Reduce via des outils comme Hadoop.
    En sus, il faut avoir une très grande masse de document pour que les analyses effectuées dans les données puissent être pertinentes !
    L'exemple typique étant la traçabilité de l'évolution de la grippe à travers les millions d'emails échangés via gmail...
    Il s'agit en pratique d'une extension de la BI, puisque l'on cherche des corrélations et des tendances à grande échelle sans ce soucier de la cause...

    Enfin, il faut noter que les grands acteurs du relationnel n'ont pas attendu la stabilité du NoSQL pour aller vers le big data. En effet tous proposent des outils pour ce faire, comme par exemple Hadoop On Azure (2012) ou Analytics Platform System (2014) pour Microsoft SQL Server...
    le 30/08/2015 à 11:17
  • Pierre Louis Chevalier
    Expert éminent sénior
    On voie passer pas mal de communications sur le NoSQL et beaucoup de gens ne savent même pas ce que c'est

    Pour ceux que ça intéresse vous pouvez faire l'effort d'aller voir au moins sur http://nosql.developpez.com

    Je pense que c'est donc utile d'en débattre, comme certains l'on fait, entre autres pour apporter leurs témoignages et expériences

    Par exemple savoir dans quel cas utiliser l'un ou l'autre, quel est son utilisation réelle sur le marché français, qu'en pensent les clients, quels sont les gains de performances dans certaines conditions à attendre de NoSQL par rapport à SQL ?

    Que certains se défoulent pour passer leurs nerfs en venant poster ici des messages genre "ce sondage est pourri" je ne trouve pas ça très constructif... Ce qui est intéressant c'est les témoignages, les avis, les benchmarks, .... c'est ça qui fait toute l'utilité sur réseau social du club...

    Si vous trouvez que les sondages que vous voyez sont pourris, c'est votre droits de le penser, et même de le dire allez (vive la liberté d'expression !), mais ça serais plus constructif de poster vos propres sondages, si vous avez des idées de sondages "intelligents" : vous postez votre message, vous avez un bouton pour ajouter un sondage, et vous cliquez sur "proposer en actualité, et voila votre sondage super intelligent est publié sur developpez.com
    le 03/09/2015 à 18:05
  • bilgetz
    Membre averti
    Envoyé par solstyce39
    Aucun des 2 je les considère plus comme 2 technologies complémentaires répondant à des besoins différents plutôt que de réel concurrent


    Totalement d'accord avec ça.
    le 28/08/2015 à 16:33
  • kilroyFR
    Membre éprouvé
    Le probleme du NoSQL c'est que ce n'est pas du tout normalisé contrairement a SQL.
    Il est tres facile de passer des requetes SQL d'un SGBDR a une autre. Il faut tout reecrire quand il s'agit de passer a NoSQL.
    De plus meme si c'est BDD revendiquent une certaine "maturité", des qu'il faut en mettre en oeuvre on tombe sur des pb d'administrations/exploitations. Car la litterature qui existe est faible meme dans les outils payants.
    Sur le principe ils ont enlevé aux BDD Relationnels tout ce qu'ils pouvaient (pas d'optimisation du stockage -> Redondance a gogo des données; la modelisation correspond aux requetes qui seront exploitées (donc quitte a redefinir N fois des choses a peu pres equivalentes); chaque BDD NoSQL a son dialecte et syntaxe (on a reproche a SQL d'etre 'compliqué'; il n'y a qu'a voir les langages (qui ressemblent a du JSON) pondus pour toutes ces BDD pour se rendre compte que ce sont des langages d'informaticien type C#/Java avec une syntaxe pour le moins barbare - donc pas toujours a la portee du quidam moyen qui ferait ses requetes ensemblistes naturellement comme on le fait avec SQL).
    La plupart des gens mettant en oeuvre ces technos sont limites labo de recherches ou sur des applis ou il y a des equipes entieres qui font la maintenance/administration dessus.

    Pour resumer ce schema que j'ai toujours trouvé tres significatif :
    http://serverdensity.wpengine.com/wp-content/uploads/2010/06/pdf-screenshot.png?w=300
    le 28/08/2015 à 19:04
  • LSMetag
    Expert confirmé
    Je répondrais simplement ceci : Question idiote !

    Chacun a son contexte d'utilisation. Le NoSQL c'est approprié pour le Big Data mais avec peu de tables, et plus performant et "pratique" dans ce cas là.
    Le SQL c'est plus pratique quand il faut faire du relationnel, avec différentes tables, des jointures, etc... Certes on a les index pour optimiser mais on n'arrive pas aux performances du No-SQL dans le même cas de figure.

    Personnellement j'utilise un "mix" qui s'appelle BrightStarDB. C'est du NoSQL à la base mais avec une part de relationnel, et possibilité d'utilisation de SPARQL, qui est un standard comme SQL. Et puis ça s'interface bien avec Entity Framework.

    Donc j'ai voté "Sans Avis" car il n'y a pas de bonne réponse.
    le 29/08/2015 à 12:40
  • zaza576
    Membre actif
    Salut à tous,

    cela dépend encore une fois du besoin.
    Pour des relations entre tables, de la lecture séquentielle de données etc... je favorise SQL.
    Pour des relations différentes (graphes, documents, ...), favoriser la montée et charge et les performances face aux principes ACID du relationnel, je prend NoSQL.

    Cela ne devrait jamais exister comme question : "Quel est votre langage préféré ?".
    On devrait plutôt inciter les gens à développer en fonction du contexte, du besoin, des exigences et des contraintes !

    Ainsi, si je demande à un stagiaire ou à un ingénieur de me faire un projet spécifique, je vais forcément regarder les choix de mes collaborateurs et leur implication dans le développement du projet.
    Si on me pond une application client serveur lourd pour une simple application web type SPA, je vais forcément ronchonner !

    Pareil pour les bases de données, pourquoi prendre NoSQL ou SQL si le besoin ne s'en fait pas sentir ?
    Vous n'allez pas forcément prendre MySQL si vous avez besoin de concevoir une appli à base de graphes (géolocalisation dans les métros parisiens).
    Vous n'allez pas forcément prendre une base de données orientée document (MongoDB) pour effectuer un simple historique (timeline, log) d'un ensemble de données du cycle de vie d'une appli.

    Make you own choices !
    le 31/08/2015 à 17:25
  • grunk
    Modérateur
    J'ai pas vraiment l'impression qu'il y'ai matière à débat.
    Les deux technologies ne sont pas faites pour gérer les mêmes problématiques.
    le 28/08/2015 à 16:29
  • fkylol
    Nouveau membre du Club
    Si on compare Operational DBMS et Relational DBMS auxquel on peut rapprocher respectivement noSQL (not only SQL) et SQL, il devient évident que le choix vient de la nature de la donnée manipulée et de son exploitation, le langage en découle. Si elle est trop hétérogène, l'effort de structuration devient démesuré par rapport au bénéfice de son exploitation et l'approche ODBMS est pertinente (et donc éventuellement le choix de noSQL).
    le 05/09/2015 à 12:23
  Poster une réponse