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.

http://www.developpez.com/public/ima...ql-nosql-1.jpg

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 :

:fleche: Quel type de SGBD utilisez-vous ? NoSQL ou relationnel ?
:fleche: Pour quelles raisons l'utilisez-vous ?
:fleche: Avez-vous déjà eu à essayer l'autre ? Quelle est votre impression ?

Liens :
:fleche: Forum SQL
:fleche: Forum NoSQL
:fleche: Tutoriels NoSQL
:fleche: La Rubrique NoSQL

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

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 :)

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.

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.

Citation:

---

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 :)

---

Pièce jointe 186607

Totalement d'accord avec ça.

Citation:

---

Envoyé par bilgetz

Pièce jointe 186607

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 ?

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

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

:fleche: 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.

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.

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.

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 :aie:

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...shot.png?w=300

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).

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.

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 :P

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

Citation:

---

Envoyé par kilroyFR

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.

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.

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.