Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« Pourquoi je ne suis pas adepte du NoSQL ? »
Un professionnel justifie ce choix sur la base de plusieurs critères

Le , par Arsene Newman

21PARTAGES

4  1 
Fondateur de CYPRESSNORTH, entreprise spécialisée dans le marketing Internet, les services IT et le développement logiciel, Matthew Mombrea explique aujourd’hui sa lassitude vis-à-vis des bases de données NoSQL.

L’un des plus grands freins vis-à-vis du NoSQL selon Mombrea est la multiplication des solutions qui partagent toute la même devise lorsqu’il est question d’en choisir une : « Cela dépend de vos besoins », alors ce qui semble être justifié et part d’un principe de bon sens se révèle être un véritable casse-tête.

En effet, même si le développeur arrive à définir ses besoins, la multitude de solutions existantes nécessite une lecture approfondie et plusieurs recherches pour saisir et comprendre toutes les facettes et les spécificités qui se cachent derrière chaque solution, ce qui ne facilite pas la tâche du développeur.

Aussi, à la lecture de ces spécificités, il n’est pas rare de s’apercevoir qu’il s’agit plus de solutions de rechanges ou de compromis vis-à-vis de certains principes comme ACID.

Plus encore, le NoSQL qui s’affranchit des tables relationnelles et qui permet un stockage de données indépendamment du type, de la forme et de la nature de la donnée, tend à créer un système hétérogène plus complexe, où le développeur doit implémenter les mêmes mécanismes existants sous les bases de données traditionnelles, pour chaque application. Ainsi, une certaine partie de l’ingéniosité et de la structuration des données derrière les bases de données relationnelles est perdu avec le NoSQL.

Alors, les performances promises par le NoSQL en matière de vitesse d’exécution, de flexibilité et de montée en charge valent elles le détour ? Pas si sûr selon Mombrea. Le besoin pour le NoSQL ne se fait ressentir que dans quelques situations, de plus la plupart des applications qui recourent au NoSQL sous prétexte d’une montée en charge, ne passeront pas finalement à une très grande échelle.

Enfin, Mombrea souligne que le NoSQL n’a pas encore suffisamment mûri pour révéler tout son potentiel, sans oublier que les bases de données relationnelles sont largement utilisées pour les sites à forte audience, ce qui révèle une certaine capacité du passage à l’échelle des solutions traditionnelles à condition de se doter d’une certaine puissance de calcul, actuellement à la portée de plus en plus d’entreprises.

Source : Article de Matthew Mombrea

Et vous ?

Pensez-vous que le NoSQL est une solution de remplacement ou une solution complémentaire aux bases de données relationnelles ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de iberserk
Membre expert https://www.developpez.com
Le 29/07/2014 à 11:32
Que les développeurs apprennent déjà à manipuler et modéliser une base de données relationnelle a peu près correctement avant de basculer (souvent pour de mauvaise raisons) sur du NOSQL.
Je rappel que le NOSQL n'a pas vocation à réellement améliorer les temps de réponse mais à assurer une montée en charge... ce qui n'est pas tout à fait la même chose.
8  0 
Avatar de L0rD59
Membre du Club https://www.developpez.com
Le 28/07/2014 à 16:10
7  0 
Avatar de spyserver
Membre confirmé https://www.developpez.com
Le 28/07/2014 à 12:23
Encore une fois le NoSQL n'est pas une solution de remplacement du SQL et n'a jamais eu vocation à l'être, simplement l'attrait d'Amazon, Facebook et autre Google pour ces bases a créé un effet de mode qui a généré beaucoup de "faux besoins" dans l'IT.

Après pour ce qui est des véritables applis qui tournent avec ce type de SGBD pour répondre à une problématique clairement identifiée (charge, type de données utilisateur peu liées entres elles mais volumineuses,persistance des données spécifique,etc.) il est clair que la "jungle" actuelle regorge de framework plus ou moins redondants qui ne facilitent pas le choix d'intégration.Le travail d'Oracle pour standardiser le langage SQL au NoSQL est une bonne chose mais il reste encore un process de selection naturelle qui doit se faire entre les différentes solutions afin de ne garder les plus stables et les plus robustes (Cassandra, MongoDB, etc.).

Recréer une nouvelle solution qui in fine est plus une évol. de quelque chose d'existant qu'une véritable révolution est assez tendance, résultat on ne sait plus quoi adopter et ça créé de l'instabilité dans les solutions et génère des coûts inutiles.
5  2 
Avatar de Haseo86
Membre éclairé https://www.developpez.com
Le 28/07/2014 à 13:41
Mode caricature : en gros ce qui gène ce monsieur c'est de devoir réfléchir pour choisir la solution adaptée ? :p

Plus sérieusement, il semble avoir une vision simpliste du monde, dans lequel il oppose absolument NoSQL et SQL. Pourtant un projet peut très bien avoir un besoin pour les deux. Je vois par exemple un projet sur lequel j'étais il y a encore un an, une partie des données étaient stockées dans une base MySQL, et une autre dans MongoDB, parce que c'était plus adapté.

Désolé si ça ne lui convient pas, mais si, il faut réfléchir en démarrant un projet, et sur bien d'autres points encore que le choix de base de données.
3  0 
Avatar de jmosqu
Candidat au Club https://www.developpez.com
Le 28/07/2014 à 14:19
J'avais lu à quelque part qu'il y avait méprise sur le terme même de NoSQL :

NoSQL <> "No SQL - renoncer au SQL"
NoSQL = "Not Only SQL"

Est-ce correct ?
2  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 19/09/2014 à 9:54
Citation Envoyé par iolco51 Voir le message
Vision simpliste.

Les bases NoSQL sont apparues parce que les bases relationnelles ACID classiques ne pouvaient pas répondre aux problématiques (montée en charge, bases hyper-relationnelles, haut volume, disponibilité).
C'est aussi pourquoi le monde NoSQL est si vaste et hétéroclite, chaque solution a été conçue pour un besoin.
Ce que vous dies est faux et participe de l'escroquerie intellectuelle qui est à la base du NoSQL. En effet, dans le fameux théorème de CAP, il est dit que les SGBDR n'était pas capable d'assurer à la fois, le transactionnel, la répartition de charge et la haute dispo... mais les tenants du NoSql ont tronqué la fin de la phrase qui est "...de manière synchrone" Or la plupart des bons SGBDR sont capable de le faire de manière asynchrone (SQL Server, Oracle et DB2).
Et aujourd'hui force est de constater que la plupart des bases NoSQL ne le font pas non plus de manière synchrone. Certes, quelques secondes pour une réplication, c'est rapide, mais c'est aussi une perte importante possible en cas de plantage !


Quand les SGBD relationnels ACID sauront gérer des petaoctets de données de facon performante, efficacement en termes de stockage, et sans un sharding manuel des données, alors le NoSQL sera bien moins intéressant.
Quand à la quantité de Po, il y a longtemps que les SGBDR en ont emmagasiné et que cela est performant. Pour info je donnais une liste de plusieurs bases de données SQL Server en Po donnant toute satisfaction : http://blog.developpez.com/sqlpro/p1...-en-petaoctets. Depuis cet article de nombeux clients ont dépassé le Po


Cela n'arrivera pas demain et les bases NoSQL ont de beaux jours devant elles car le volume de données à traiter croit exponentiellement.
Bref, du grand n'importe quoi....

En fait les bases de données NoSQL ne sont intéressante que pour des données qui ne sont pas dans l'informatique de gestion (ventes, compta, production...) mais dans l'informatique documentaire (blogs, mail...) ou en complément de bases relationnelles.
Or comme la plupart des éditeurs de SGBDR traditionnels (Oracle, MS, IBM...) sont en train d'intégrer cela à leur moteur, les cassandra et autres acteurs de la chose qui ne sont pas encore économiquement rentables sont condamnés d'avance !

A +
2  0 
Avatar de skuatamad
Expert confirmé https://www.developpez.com
Le 20/10/2014 à 19:20
Tout d'abord je n'ai pas critiqué les produits NoSQL que d'ailleurs je ne connais pas (mais ta 1ere remarque ne s'adressait probablement pas à moi).

Après je ne suis pas d'accord avec une remarque :
Citation Envoyé par hugo123 Voir le message
j'ai toujours vu ces débats DBA/Devs tourner de la sorte. Il y a longtemps il y a eu le débat procédures stockées Vs code applicatif (ou ORM) et la fameuse politique de "base interdite en écriture pour les devs sauf a executer mes procs stocks".
Les DBA ne développent pas de procédures stockées applicatives, ça n'a jamais été leur rôle.
C'est le rôle des développeurs, mais à mon sens de développeurs spécialisés dans LA base de données utilisée.
Certes ce modèle n'existe plus, d'où, à mon sens, l'apparition d'ORM, mais à mon sens toujours c'est plus lié à un problème de gestion de ressource / management.

Les développeurs applicatifs ont déjà fort à faire avec le langage qu'ils utilisent (voir les langages), en plus ils doivent bosser potentiellement sur plusieurs SGBDR, et pis bon un peu d'IHM en prime...
Du coup ils ont généralement tendance à considérer que les SGBDR fonctionnent tous de la même manière, et pense rarement voir très rarement concurrence d'accès.

Je ne doute pas que les gens que tu cites sont très compétents, par contre le blogueur à l'origine de la création de cet article dit des choses plus que surprenantes :
http://www.developpez.net/forums/d14...l/#post7911596
2  0 
Avatar de hugo123
Rédacteur https://www.developpez.com
Le 20/10/2014 à 20:47
Le débat code applicatif Vs proc stock est encore d'actualité. Je le rencontre encore régulièrement dans les sociétés. C'est parfois caricatural, avec des silos complètement étanches qui mènent à des situations ubuesques
Dans certaines sociétés j'ai vu la situation changer entre deux CTO, le premier venait du dev, le second qui l'a remplacé venait des DBDev (dev de base de données). Bref, de la querelle de clocher, comme tu dis, des soucis de management.

Pour ma part je trouve un peu dommage de maintenir des silos de compétence. Je trouve un peu réducteur d'avoir des devs qui ne ferait que du langage sans connaitre la base de données qu'ils utilisent ou des DBdev ne connaissant pas comment les données sont utilisées de façon applicative etc... J'ai bossé dans des équipes un peu plus polyvalentes et c'est celles qui tournaient le mieux selon moi.
Il y aurait bcp à dire sur le sujet.

a+
2  0 
Avatar de -kiki-
Membre du Club https://www.developpez.com
Le 21/10/2014 à 11:17
tu caricature le débat pour essayer de nous dé-crédibiliser?
je ne suis pas DBA, mais un dev php de base. donc ce n'est pas une querelle de clocher DBA vs DEV (car dans ta logique mon discours serait celui d'un DBA à l'encontre des DEVS?).
mais j'aime être fier de ce que je fais, et j'aime avoir de vraies discussions techniques.
donc je n'aime pas qu'on me contredise sans argumenter, et je déteste qu'on m'impose des solutions techniques ineptes.
du coup j'ai souvent envie de me tirer une balle :p je pense d'ailleurs me réorienter vers du dev client, où je redeviendrais un noob parmis les noobs.

et le problème de l'ignorance est justement au coeur de mes petits problèmes pro :
biensûr qu'il y a des gens compétents! mais le problème c'est qu'ils sont rares, et que les incompétents boivent leurs paroles sans les comprendre, et essaye d'imposer leurs idées biaisées partout où ils passent!
-> impossible de discuter avec eux car au final ils ne pigent même pas les arguments qu'on leur avance, et petit à petit ils modifient négativement notre environnement technique.
et ce n'est pas un faux débat, on sait très bien que l'idée n'est pas d'opposer le NoSql au sql!
ce que je déplore, ce n'est pas d'avoir du NoSql dans certains projets, c'est d'avoir du NoSql là où un SGBDR aurait été plus adapté (et de ne même pas avoir la possibilité d'en débattre).
mais je sais que je tire des généralités à partir de ma seule expérience...
et le NoSql n'est pas le seul sujet qui gâche mon quotidien, y'a aussi les ORM par exemple :p

Désolé d'avoir un peu raconté ma vie (et d'avoir été si prétentieux, et d'avoir trollé...^^), mais comme ça tu comprend peut-être mieux mon point de vue.

ps: tu fuyais la discussion pour éviter ce genre de débat, mais tu y plonge dès qu'on ouvre la porte :p
2  0 
Avatar de spidetra
Membre confirmé https://www.developpez.com
Le 30/07/2014 à 9:47
Citation Envoyé par iolco51 Voir le message
Vision simpliste.

Les bases NoSQL sont apparues parce que les bases relationnelles ACID classiques ne pouvaient pas répondre aux problématiques (montée en charge, bases hyper-relationnelles, haut volume, disponibilité).
Tu aurais des exemples de bases hyper-relationnelles ? C'est une notion que je ne connais pas.
Est-ce que tu fait référence aux bases orientés graphes et aux hyper-graphes ?
1  0