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 !

Base de données relationnelle ou NoSQL, laquelle constitue le meilleur choix ?
Un développeur défend les SGBDR après avoir abandonné NoSQL

Le , par Cedric Chevalier

241PARTAGES

2  4 
Matt Butcher est un développeur logiciel qui travaille pour la compagnie Revolv basée aux États-Unis. Revolv propose du matériel (ampoules électriques, thermostats, serrures, etc.) pour implémenter le concept de « Smart Home » qui donne la possibilité aux utilisateurs de contrôler avec leurs smartphones ou tablettes les périphériques de leur maison.

Ces équipements interconnectés génèrent un flot d’informations que Revolv gérait avec les systèmes de gestion de base de données non relationnelle. Mais ça, c’était avant. En effet, la firme a décidé d’abandonner le NoSQL, pour retourner à la gestion classique avec les bases de données relationnelles (via PostgreSQL).

Pourquoi ce subit changement ? Le développeur de la maison (Matt) présente trois points essentiels qui les ont poussés à faire ce choix. Le premier relève même de la nature des bases de données non relationnelles. Pour Matt, elles ne prennent pas correctement en charge les relations. Or, les données sur lesquelles ils sont amenés à travailler sont fortement relationnelles.

La seconde observation de Matt, c’est que l’écriture de la syntaxe pour le retrait d’information dans la base de données non relationnelle peut s’avérer complexe. Spécialement dans le cas de Revolv, où la solution employée n’avait pas de langage de requête intermédiaire. Par conséquent, il fallait écrire du code complexe pour chaque requête.

La troisième raison est relative à la documentation. Matt trouve que celles des bases de données NoSQL sont fragmentées et manquent de maturité par rapport à leurs équivalents chez les SGBDR. Ce qui constitue d’après lui un énorme handicap. Il dira même qu’il a passé énormément de temps à rechercher dans les documentations des configurations qui s’avéraient au final triviales.

Des points de vue certes personnels, mais qui alimentent l’éternelle bataille entre fervents défenseurs des technologies de base de données relationnelles à leurs homologues NoSQL. Plusieurs arguments sont souvent évoqués par les défenseurs du NOSQL.

On peut lire très souvent, « L’opération join employée pour les bases de données relationnelles est un réel handicap lorsqu’elle se fait pour un grand nombre d’éléments. Google l’a compris et développé sa propre solution. De plus, elles ne sont pas parfaitement adaptées pour les données telles que le XML ou encore les objets complexes. »

Ce à quoi répondent les fervents défenseurs des bases de données relationnelles en argumentant qu’à « chaque type de donnée, correspond au moins un modèle relationnel. Il en est de même pour le XML et les objets complexes. De plus, de nos jours l’opération Join ne constitue plus un problème. Avec des acteurs comme Oracle, elle peut être exécutée sans crainte pour des gros systèmes ».

Source: Technosophos

Et vous ?

Êtes-vous un fervent défenseur des bases de données relationnelles ou NoSQL ?

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

Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 17/04/2014 à 15:46
Quand on besoin de gérer beaucoup de relations, une base de données relationnelle serait un meilleur choix qu'une base de données orientée document genre MongoDB ou qu'une base clé-valeur genre Cassandra ?

Sans déconner ???

De la même manière, je me suis rendu compte que j'arrivais vachement mieux à enfoncer des clous avec un marteau qu'avec une pelle à tarte ! Etonnant, non ?

10  0 
Avatar de coolspot
Membre confirmé https://www.developpez.com
Le 16/04/2014 à 18:51
Question totalement stupide, il n'y a pas de solution meilleurs que d'autre mais des besoins différent ou chacune des deux solutions peut être la meilleur au grès du besoin.

Bref cette question du meilleurs est aussi stupide que si l'on affirmait que C++ c'est meilleur que Java.
9  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 17/04/2014 à 14:07
Citation Envoyé par Gugelhupf Voir le message
Quand je vois la syntaxe NoSQL de MongoDB (c'est du JS ), comparé au SQL ça fait peur :


Là encore ça va, mais les requêtes SQL que je met en place ne sont pas aussi simples que dans cet exemple.
Sans entrer dans les détails des SGBDR vs bases NoSQL, le langage SQL à lui seul est très puissant.

PS: Je ne sais pas si vous avez remarqué mais l'exemple JavaScript me fait penser à l'API Stream de Java 8
C'est du Javascript, quoi. Ce qui rallonge beaucoup, c'est la phase de mapping, puisque MongoDB est schemaless.

Après, si on veut modifier la structure des données qu'on veut stocker, ça se fait de manière transparente, sans interruption du système, par exemple. Pas besoin de faire un ALTER TABLE plutôt acrobatique quand on fait ça sur une table avec 10 millions d'entrées.

On peut multiplier les exemples dans les deux sens sans rien démontrer...
4  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 17/04/2014 à 17:33
Il faut aussi se dire que le SQL c'est 40 ans de travail, c'est un langage qui évolue constamment.

Je ne remet pas en cause JS/MongoDB, mais si je ne peux pas faire de jointure qui vont dans tous les sens pour récupérer des chiffres plus ou moins complexes, le NoSQL ne me sert à rien pour ma part.
4  0 
Avatar de redcurve
Membre confirmé https://www.developpez.com
Le 19/04/2014 à 11:04
Citation Envoyé par Gugelhupf Voir le message
Il faut aussi se dire que le SQL c'est 40 ans de travail, c'est un langage qui évolue constamment.

Je ne remet pas en cause JS/MongoDB, mais si je ne peux pas faire de jointure qui vont dans tous les sens pour récupérer des chiffres plus ou moins complexes, le NoSQL ne me sert à rien pour ma part.
En tant que développeur je pense que ces bases vont se démocratiser mais pas forcément pour de bonnes raisons. Beaucoup sont très mal formés à la conception d'une base de données notamment via la méthode MERISE (on oublie UML qui est horrible pour ça).

En outre, beaucoup ne veulent pas apprendre et pense qu'il suffit d'utiliser des outils (comme si avoir une scie faisait de toi un charpentier ...), comme un ORM et que hop on glisse n'importe nawak dans le designer et voilà on a une base de données.

La quintessence du grand n'importe quoi concernant les bases de données c'est le code first, du coup on se retrouve avec des DB au schéma capilotracté , et après tu passes 4 jours à faire des scripts SQL pour modifier pratiquement tout le schéma de la db et créer des index etc. parce que des débiles croient en la magie. Mais à la fin du es content quand les perfs sont multipliés par 10 avec le même serveur sql.

Les bases NoSql sont bien mais pas quand tu as de l'information structuré (et encore ça dépend quoi), mais surtout l'absence de transaction de contrôle d'intégrité etc. n'est pas très rassurant. Dans le cas ou la perte de données est permise pourquoi pas, par exemple j'utilise Couchbase pour stocker des logs, si je perds quelques logs en cours de route ce n'est pas très grave.

La base de données "Nosql" que j'utilise le plus est Berkeleydb que j'ai wrapper dans des collections dotnet, du coup j'ai des collections du type :

Code : Sélectionner tout
1
2
3
4
DuplicatePersistentDictionary<TKey, TValue>
PersistentDictionary<TKey, TValue>
PersistentHashTable<TKey, TValue>
PersistentQueue<TValue>
Berkeley supporte les transactions ACID, la réplication, la mise en cluster etc. rien à voir avec les db key/value ayant le vent en poupe et dont l'implémentation est sacrément primitive à coté.

Je vais faire des

Code : Sélectionner tout
1
2
3
4
5
DistributedDuplicatePersistentDictionary<TKey, TValue>
DistributedPersistentDictionary<TKey, TValue>
DistributedPersistentHashTable<TKey, TValue>
DistributedPersistentQueue<TValue>
Mais ça c'est pour le fun.
4  0 
Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 20/04/2014 à 19:39
Citation Envoyé par redcurve Voir le message
En tant que développeur je pense que ces bases vont se démocratiser mais pas forcément pour de bonnes raisons. Beaucoup sont très mal formés à la conception d'une base de données notamment via la méthode MERISE (on oublie UML qui est horrible pour ça).

En outre, beaucoup ne veulent pas apprendre et pense qu'il suffit d'utiliser des outils (comme si avoir une scie faisait de toi un charpentier ...), comme un ORM et que hop on glisse n'importe nawak dans le designer et voilà on a une base de données.

La quintessence du grand n'importe quoi concernant les bases de données c'est le code first, du coup on se retrouve avec des DB au schéma capilotracté , et après tu passes 4 jours à faire des scripts SQL pour modifier pratiquement tout le schéma de la db et créer des index etc. parce que des débiles croient en la magie. Mais à la fin du es content quand les perfs sont multipliés par 10 avec le même serveur sql.

Les bases NoSql sont bien mais pas quand tu as de l'information structuré (et encore ça dépend quoi), mais surtout l'absence de transaction de contrôle d'intégrité etc. n'est pas très rassurant. Dans le cas ou la perte de données est permise pourquoi pas, par exemple j'utilise Couchbase pour stocker des logs, si je perds quelques logs en cours de route ce n'est pas très grave.
C'est déprimant, tu viens de décrire exactement mon environnement de travail...

J'ai tous les ingrédients décrits plus haut :
- gens très mal formés à la conception d'une base de données
- ne veulent pas apprendre (pire : ils crachent sur le SQL)
- pensent qu'il suffit d'utiliser un ORM pour que ça marche
- problèmes de perfs
- on ne peut pas se permettre de perdre des données, et pourtant on utilise du NoSQL

Du coup, je trouve ton analyse extrêmement pertinente.
4  0 
Avatar de Bono_BX
Membre confirmé https://www.developpez.com
Le 16/04/2014 à 17:13
Pour Matt, elles ne prennent pas correctement en charge les relations. Or, les données sur lesquelles ils sont amenés à travailler sont fortement relationnelles.
Je ne suis que partiellement d'accord avec ce premier argument, car, bien qu'à part dans le monde NoSQL, les bases de données orientées graphes gèrent très bien les relations, elles sont même faites pour. Après, leur complexité est vraiment énorme.

Pour le reste, je rappelle que NoSQL signifie Not Only SQL, et n'a donc pas vocation à remplacer les SGBD-R. On en revient encore une fois au traditionnel "le bon outil pour le bon emploi".
3  0 
Avatar de atha2
Membre éprouvé https://www.developpez.com
Le 16/04/2014 à 20:12
Citation Envoyé par Bono_BX Voir le message
Je ne suis que partiellement d'accord avec ce premier argument, car, bien qu'à part dans le monde NoSQL, les bases de données orientées graphes gèrent très bien les relations, elles sont même faites pour.
Ma question peut aussi paraitre stupide mais qu'elle différence fait tu entre une BDD NoSQL orientées graphes et une BDD relationnelle ? Pour moi (0 expérience sur NoSql ) c'est la même chose... Au API et SGBD utilisé prés. Si on a besoin de relations, autant utiliser une BDD relationnelle, non ?

Sinon, c'est dommage que cette news ne reprenne pas la conclusion de l'article original qui en gros précise :
  • que s'ils n'ont pas gardé NoSql, c'est parce qu'il ne correspondait pas leurs besoins
  • que NoSql ne doit pas être utiliser parce que c'est à la mode mais s'il répond à nos besoin (mieux qu'un SGBDR)
  • que NoSql est jeune, fragmenté et manque d'outil (analyse de perf, import/export...) et d'une documentation complète
3  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 16/04/2014 à 23:11
Quand je vois la syntaxe NoSQL de MongoDB (c'est du JS ), comparé au SQL ça fait peur :


Là encore ça va, mais les requêtes SQL que je met en place ne sont pas aussi simples que dans cet exemple.
Sans entrer dans les détails des SGBDR vs bases NoSQL, le langage SQL à lui seul est très puissant.

PS: Je ne sais pas si vous avez remarqué mais l'exemple JavaScript me fait penser à l'API Stream de Java 8
4  1 
Avatar de teddyFry
Membre à l'essai https://www.developpez.com
Le 17/04/2014 à 11:08
Ce problème est récurrent depuis l'arrivée des bases de données noSQL. A savoir que comme on ne participe pas à une course de voiture avec un tracteur, on ne va pas labourer un champ avec une formule un.
Il est surtout nécessaire de choisir le bon outil pour répondre à la problématique initiale. Et il est sûr que vouloir faire du relationnel avec du noSQL mènera sûrement à l'échec du projet. D'ailleurs en grande partie dû à des problèmes de performances alors que c'est ce qu'on vient chercher en premier quand on se lance dans l'aventure du noSQL.

Choisir une base orientée document comme mongoDB, c'est vouloir travailler avec des documents souvent non structurés d'ailleurs. Ou encore faire beaucoup plus d'écritures que de lectures. Bref faire souvent du data minning dans des terra de données même si de tels systèmes ne se limitent pas à ça. Tout ça avec des performances époustouflantes par rapport à du SGDB classique. SGDB classique qui rivalisent d'ingéniosité pour offrir des fonctionnalités du type "Big Data" avec des choses comme "Columnstore Indexes" ou autre. Tout ça parce que ce genre de système bat des records en scalabilité.

Il existe une multitude de bases de données noSQL, orientées graph, clef/valeur, document, colonne, ... qui répondent à une multitude de problématiques. Il est sûr que choisir le mauvais outil ou le mauvais modèle de données, c'est se tirer une balle dans le pied directement. Le discours de ce monsieur est surtout un aveu d'échec face à la mauvaise solution qu'il à choisi.

Pour conclure il est plus facile de critiquer une base de données parce qu'elle n'apporte pas ce qu'elle promet que d'avouer que la solution que l'on a choisi n'était pas du tout adaptée...
3  0