Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

SQL Vs NoSQL, quel est votre préféré ? participez au débat et donnez-nous vos avis


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Expert éminent sénior
    SQL Vs NoSQL, quel est votre préféré ? participez au débat et donnez-nous vos avis
    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
    Vous avez envie de contribuer au sein du Club Developpez.com ?

    Vous êtes passionné, vous souhaitez partager vos connaissances en informatique, vous souhaitez faire partie de la rédaction.
    Il suffit de vous porter volontaire et de nous faire part de vos envies de contributions :
    Rédaction d'articles/cours/tutoriels, Traduction, Contribution dans la FAQ, Rédaction de news, interviews et témoignages, Organisation de défis, de débats et de sondages, Relecture technique, Modération, Correction orthographique, ...etc.
    Vous avez d'autres propositions de contributions à nous faire ? Vous souhaitez en savoir davantage ? N'hésitez pas à nous approcher.

  2. #2
    Expert éminent sénior
    SQL, parceque dans toutes les boutiques ou je suis passé, il n'y avait que ça.

    Après, le noSQL a certainement des qualités, c'est juste que je ne les connais pas...
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #3
    Membre actif
    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

  4. #4
    Membre confirmé
    SQL, car je ne connais pas le NoSQL et ce qu'il apporte
    Ayant eu à développer sous Lotus Notes durant quelques années, j'avais laissé tomber le relationnel et donc le SQL.
    Ayant à developper des sites techniques en PHP avec Mysql, j'ai laissé tomber le modèle relationnel pur, car trop rigide,
    pour un système souple de tables représentées dans des classes (Persistance), respectant ou non les contraintes d'intégrité selon la demande du client,
    mais modifiable rapidement.

  5. #5
    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  6. #6
    Membre averti
    Citation Envoyé par solstyce39 Voir le message
    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.

  7. #7
    Membre régulier
    Citation Envoyé par bilgetz Voir le message


    Totalement d'accord avec ça.
    +1 aussi

    Par ailleurs, je ne vois pas la relation de cause à effet dans la phrase "Le NoSQL s'est véritablement répandu après le meetup NoSQL qui a eu lieu le 11 juin 2009 à San Francisco [...]. C'est d'ailleurs l'une des raisons pour lesquelles le langage JavaScript connait un réel essor.". Quelqu'un pour m'expliquer ?

  8. #8
    Membre confirmé
    Comme dit plus haut, SQL et NoSQL ne couvrent pas les mêmes besoins (NoSQL = Not Only SQL).
    Donc aucun des deux.

  9. #9
    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.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  10. #10
    Expert confirmé
    Sur le plan théorique le modèle relationnel n'est qu'un modèle particulier d'organisation des données. Les solutions dites "NoSQL" se sont avant tout attachées à supporter d'autres modèles mais en réalité les produits se mettent à supporter plusieurs modèles: certains SGBD relationnels supportent des modèles non-relationnels, les modèles NoSQL supportent du relationnel. Le fait que nous nous soyons quasiment cantonnés au seul modèle relationnel pendant des décennies n'a été qu'une aberration.

    Poser un débat SQL vs NoSQL revient à poser un débat "relationnel pour tout le monde du soir au matin" ou "la solution qui vous convient le mieux". Et la réponse est évidente. Même si dans bien des cas c'est le relationnel qui convient le mieux, en partie du fait de la maturité des solutions relationnelles.

  11. #11
    Membre chevronné
    Franchement, le débat ne se pose pas du tout en ces termes. C'est un peu comme demander quel est votre outil préféré, un marteau ou une scie ?

    Pour la plupart des applications, une base de données relationnelle me parait indispensable, pour stocker... ben les relations entre les différentes informations. Après, générer des éléments prêts à l'emploi dans un MongoDB, par exemple, ça peut considérablement accélérer une application web.
    J'appelle "Point Traroth" le moment dans une discussion où quelqu'un parle des Bisounours. A partir de ce moment, toute discussion sérieuse devient impossible, puisque la légitimité d'une des parties pour exposer son point de vue est mise en cause. C'est juste un anathème, un moyen de décrédibiliser les autres sans avoir à discuter.

  12. #12
    Membre extrêmement actif
    Difficile de répondre à la question, je ne connais pas du tout nosql.
    Par contre niveau sqldb j'en ai fait une tripotée sérieusement: dbase3, 4, (clipper), access, teradata, sql server, oracle, sqllite et maintenant je me mets à mysql (mariaDb) ^^
    J'ai optimisé un query de 7.5 sec à 0.33 sec grâce à des aggrégateurs "sum(case...)" au lieu de faire des select de select.
    La syntaxe qui m'a sauvé la vie lol.
    Rem: je vais jeter un coup d'oeil aux tutos, merci
    Si la réponse vous a aidé, pensez à cliquer sur +1

  13. #13
    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

  14. #14
    Membre éprouvé
    Pour avoir realiser des tests de perfs entre Oracle et MongoDB.

    Quand dans un modele Oracle, on enleve toutes contraintes d'integrité referentielles (pas de Foreign Keys), on doublonne les données dans tous les sens, on met des indexes correspondants aux requetes attendues ... on arrive aux memes performances que les BDD NoSQL (en utilisant une syntaxe universelle SQL).
    Le pb de ces BDD c'est de choisir la bonne (chacune a ses + et ses -). Le temps passé a se former sur l'une n'est pas perein si on veut passer a une autre BDD NoSQL (il faut tout reapprendre car les langages/principes ne sont pas tous les memes).
    A part pour des applis ultra specifiques (type moteur de recherche ou autre) je ne vois pas trop l'interet; chez nous on a abandonné car depenser une energie/argent sur des technos dont on ne connait pas la perenité sur 10 ans c'est limite.
    Alors on reste sur les technos SQL que tout le monde maitrise (pas besoin de se former aux nouvelles syntaxes incomprehensibles/difficiles a maintenir a moins d'avoir passé 5 ans sur le sujet).

  15. #15
    Membre éprouvé
    C'est juste dans les dernieres versions de ces moteurs qu'ils reinventent la notion de TRANSACTION, JOINTURE etc. bref petit a petit ils rajoutent tout ce qui existait dans SQL et qu'ils ont enlevé parce qu'ils voulaient se focaliser sur les perfs exclusivement. Nul doute que pour des applis type moteur de recherche c'est utile mais pour des applis de gestion avec du transactionnel etc. on retombe sur les memes problématiques; ils n'ont rien resolu de ce coté la.

  16. #16
    Membre extrêmement actif
    kilroyFR >> "700 000 recherches par seconde sont gérées par Google, 98 000 nouveaux tweets par seconde"
    Ce sont des chiffres énormes que j'ai trouvé dans une doc nosql de 2012 sur ce site.
    Peut-être que ça vaut qu'en même la peine d'y jeter un coup d'oeil
    Si la réponse vous a aidé, pensez à cliquer sur +1

  17. #17
    Membre éprouvé
    oui parfaitement adapté pour des moteurs de recherche - ce que j'ai dit/experimenté mais pas pour des applis transactionnelles classiques

  18. #18
    Membre extrêmement actif
    Citation Envoyé par kilroyFR Voir le message
    oui parfaitement adapté pour des moteurs de recherche - ce que j'ai dit/experimenté mais pas pour des applis transactionnelles classiques
    mais ils doivent bien faire des INSERT lorsqu'ils twittent
    probablement des auto commit.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  19. #19
    Membre éprouvé
    Oui, operations unitaires sans aucun verrouillage donc rapides (aucun controle de FK etc) - applique les memes regles a n'importe quelle SGBDR SQL et tu auras les memes perfs.

  20. #20
    Membre habitué
    Ce sondage n'a pas de sens!!
    On ne peut pas comparer ce qui n'est pas comparable. C'est comme comparer un tournevis et un marteau, ça n'a aucun rapport, c'est 2 outils qui servent mais dans des situations totalement différentes.

###raw>template_hook.ano_emploi###