IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Affichage des résultats du sondage: Quel est selon vous le meilleur SGBD ?

Votants
46. Vous ne pouvez pas participer à ce sondage.
  • SQL

    34 73,91%
  • NoSQL

    3 6,52%
  • Pas d'avis

    9 19,57%
Décisions SGBD Discussion :

Quel est selon vous le meilleur SGBD : SQL ou NoSQL ?


Sujet :

Décisions SGBD

Vue hybride

Coriolan Quel est selon vous le... 22/03/2017, 01h40
philouZ Perso je n'utilise pas de... 22/03/2017, 04h30
SurferIX C'est ce raisonnement qu'il... 31/03/2017, 13h44
dukoid ça n'a aucun sens ce que tu... 31/03/2017, 21h14
RyzenOC je sais pas si SQL est plus... 22/03/2017, 08h09
grunk Comparer du relationnel et du... 22/03/2017, 08h16
sbeex Et la réponse les 2 sont bien... 22/03/2017, 09h11
SQLpro Hélas ce genre d'erreur est... 22/03/2017, 16h20
Aurelien.Regat-Barrel +1 LE SQL c'est bien quand... 22/03/2017, 16h43
SQLpro Autrement dit vous dites... 22/03/2017, 16h13
myNameIsFlo Quel est selon vous le... 22/03/2017, 09h10
vanskjære Pour ma part je n'ai eu à... 22/03/2017, 09h40
TheGuit Déjà la question est débile... 22/03/2017, 10h08
melka one ce qui en resort c'es que sql... 22/03/2017, 11h01
Shepard Quels sont tes arguments pour... 22/03/2017, 14h19
SQLpro Vous avez raison sur le fond... 22/03/2017, 16h34
sitexw Regarde quelques benchmark... 22/03/2017, 15h44
kilroyFR Alors totalement d'accord sur... 22/03/2017, 21h40
dsoftbbm Pour moi dsoftbbm ! ce SQL... 31/03/2017, 15h16
Laurent Simon La question est stupide. SQL... 11/04/2017, 11h49
Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éprouvé
    Avatar de Coriolan
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2016
    Messages
    702
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2016
    Messages : 702
    Par défaut Quel est selon vous le meilleur SGBD : SQL ou NoSQL ?
    Quel est selon vous le meilleur SGBD : SQL ou NoSQL ?
    Un développeur pense que vous devez opter pour SQL

    En août dernier, une étude a montré la montée en puissance du NoSQL, avec de plus en plus d’entreprises qui se tournent vers le cloud public. Ce constat peut être expliqué par plusieurs facteurs, notamment la performance des nouveaux systèmes NoSQL qui reste bonne avec la montée en charge (scalabilité) en multipliant simplement le nombre de serveurs, solution raisonnable avec la baisse de coûts.

    Mais tout le monde ne semble pas être convaincu que le NoSQL constitue une solution optimale et peut remplacer les bases de données SQL. Certains ont même regretté d’avoir opté pour les bases de données non relationnelles au lieu du bon vieux SQL.

    Les mauvaises raisons pour choisir NoSQL

    Dans son article, Paris Kasidiaris a listé selon lui les mauvaises raisons qui poussent les développeurs à recourir aux bases de données NoSQL. Dans la plupart des cas, ce choix est dû à une connaissance superficielle du sujet.

    Plus facile pour les développeurs

    Comparer la façon d’écrire un document dans le magasin de données contre l’écriture d’une nouvelle base de données avec INSERT constitue le meilleur moyen pour comparer la facilité d’utilisation de chaque solution NoSQL et SQL. En effet, l’écriture d’un objet JSON directement dans le magasin de données est plus facile qu’avoir recours à une requête SQL INSERT.

    Maintenant, si on compare par exemple la façon de récupérer les utilisateurs qui se sont inscrits sur une application durant les 24 dernières heures :

    Avec MySQL

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    SELECT  *
    FROM    users
    WHERE   signup_time >= CURDATE() - INTERVAL 1 DAY
    vs. Mongo

    db.users.find({
    "signup_time": {
     $gt: new Date(Date.now() - 24*60*60 * 1000)
    }
    })
    Dans le premier cas, on utilise un langage ayant des mots que les humains utilisent pour communiquer entre eux. Le deuxième cas au contraire est écrit en JavaScript, et vous êtes dans l’obligation de créer votre requête avec un objet JSON et même convertir les 24 heures en millisecondes.

    Et ce n’est pas fini, si vous voulez récupérer de la base de données tous les utilisateurs qui se sont inscrits la semaine dernière et se sont connectés au moins deux fois, vous êtes dans de beaux draps.

    Une simple requête relationnelle comme celle-ci ne peut tout simplement pas être exprimée directement dans un magasin de données NoSQL, mais elle peut être utilisée en SQL (une seule requête SQL ou ORM : mapping objet-relationnel). Pour contourner cette limite du NoSQL, le développeur doit recourir à la dénormalisation, c’est-à-dire la copie des mêmes données dans plusieurs documents ou tables afin de simplifier et optimiser le traitement des requêtes ou pour ajuster les données à la demande pour l’utilisateur. Une autre solution consiste à utiliser MapReduce.

    Meilleure prise en compte de la montée en charge

    Cet argument est souvent avancé par les partisans du NoSQL, mais encore faudrait-il d’abord que la scalabilité soit un problème pour le développeur et que le NoSQL soit plus performant que les solutions SQL lors de la montée en charge.

    D’abord, la montée en charge n’est pas et ne sera peut-être jamais un problème, à part si le développeur doit faire face à des milliers de requêtes par seconde et des terrabytes de données dans sa base de données. Et même au cas où vous êtes amené à un tel scénario, des solutions (fully managed) comme AWS RDS existent.

    La deuxième hypothèse est aussi erronée, NoSQL n’est pas plus performant que SQL lorsqu’il s’agit de montée en charge. MySQL est utilisé par quelques-uns des sites web les plus populaires de la planète comme Facebook, Twitter, GitHub, Basecamp et à peu près toutes les installations de PHP. Ces sites comme on peut le constater n’ont pas trouvé de soucis avec les SGBD SQL malgré l’énorme trafic qu’ils reçoivent.

    Une vitesse d’écriture plus rapide

    Cette supposition est vraie, mais en tant que développeur, est-ce que votre application a vraiment besoin d’écritures rapides ? À part si vous allez exécuter un service de logging ou quelque chose de similaire, dans la plupart des cas, toutes les applications se ressemblent et ont un but commun : une personne propose un contenu qui sera consommé par d’autres personnes. C’est la façon avec laquelle fonctionne le web aujourd’hui, Facebook, Twitter, YouTube, les services de partage de fichiers, votre application ne fera surement pas exception.

    Ce sont donc les principales mauvaises raisons qui poussent les développeurs à choisir le NoSQL contre SQL. Ce qui est malheureux, c’est qu’elles sont mises en avant par le site web officiel de MongoDB, un site qui a surement joué un rôle vital dans cette illusion.

    Les bonnes raisons pour choisir une base de données SQL

    Chaque technologie utilisée a ses points forts et ses points faibles, et SQL ne sort pas du lot. Voici pourquoi SQL est presque le bon choix pour tout type d’application web.

    L’écosystème

    L’écosystème de SQL est juste imbattable, c’est un langage qui date de 1974, donc plus de 40 ans d’existence. Pour cette raison, les développeurs sont devant un nombre énorme d’outils et de services auxquels ils peuvent recourir.

    SQL est enseigné dans toutes les universités et les écoles d’informatique du monde. Les solutions matures de SQL ne manquent pas, de PHPMyAdmin et SQLAlchemy à Pony ORM. Les opérateurs cloud publics proposent également des bases de données SQL en tant que service que vous pouvez utiliser sans effort (Amazon RDS, Google Cloud SQL and Azure SQL Database).

    Les transactions et les propriétés ACID

    SQL offre une chose que tous les gens responsables d’applications web en production cherchent à assurer, la tranquillité d’esprit à propos de leurs données. Cela est dû au fait que toute solution SQL dans le marché vous permet de regrouper plusieurs requêtes SQL dans des unités de travail conforme au standard ACID (appelées transactions).

    En pratique, cela veut dire que vous pouvez entrer des changements sur votre base de données regroupés en une seule transaction. Vous pouvez mener toute requête qui concerne des opérations de transaction, comme start transaction, commit, ou rollback, tout en étant sûr de garantir l’atomicité, la cohérence, l’isolation et la durabilité de votre transaction.

    En d’autres termes, avec SQL, vous pouvez être sûr d’arriver à votre objectif sans avoir de mauvaises surprises.

    Le stockage

    Un autre aspect important des systèmes de base de données SQL pour les applications en production est sa capacité à faire des économies sur l’espace de stockage. En effet, SQL a besoin d’une structure de table prédéfinie pour enregistrer les données. Cela permet d’enregistrer seulement les contenus dans chaque ligne et chaque colonne dans le disque. Au contraire, avec les solutions NoSQL, vous aurez à enregistrer tout le document (toutes les valeurs) sur le disque, puisqu’il n’existe pas de structure prédéfinie pour les documents stockés dans chaque collection. Plus vos données deviennent importantes, plus le problème s’amplifie avec plusieurs gigabytes de données NoSQL.

    Cet article ne vise pas à chahuter les magasins de données NoSQL. Loin de là, il y a des solutions NoSQL dans le marché qui sont utilisées dans presque tout type d’application web en production. Il s’agit ici de montrer qu’il ne faut pas considérer NoSQL comme une solution à tous nos problèmes de stockage de données, pour la simple raison que cette solution parait être simple. On a déjà des solutions SQL matures et bien établies qui ont déjà fait leurs preuves et répondent à tous nos besoins en la matière.

    Source : stateofprogress.blog

    Et vous ?

    Que pensez-vous de cette nouvelle tendance qui cherche à forcer l'usage du NoSQL ?

    Voir aussi :

    Forum Décisions SGBD

  2. #2
    Membre Expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2003
    Messages
    1 006
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Mai 2003
    Messages : 1 006
    Par défaut
    Perso je n'utilise pas de NoSQL car je n'en ai absolument pas l'utilité. A mon sens le NoSQL ne peut avoir un intérêt que dans l'utilisation du big data avec un volume de donnée extrêmement important et je ne suis pas encore dans ce cas.

    Pour du site web, des appli principalement accès gestion, du développement mobile avec accès par webservices, je n'utilise que du SQL. C'est peut-être aussi parce que je maitrise ce que je fais et que je n'ai pas besoin de me former pour l'utiliser (même si on en apprend tous les jours).

    Pour répondre à la question
    Que pensez-vous de cette nouvelle tendance qui cherche à forcer l'usage du NoSQL ?
    Je pense que ça fait plus effet de mode. Comme beaucoup de choses, ça vient de sortir alors vite tout le monde se précipite dessus et dit qu'il n'y a pas mieux. J'en vois encore qui me disent : "Comment tu n'es pas passé au big data ?".

    J'attends les retours d'expériences mais je ne suis pas sûr qu'il y ait tant de monde que ça qui passe au NoSQL. La part restera faible à mon sens.

    Chaque outil a son utilité...

  3. #3
    Membre très actif

    Homme Profil pro
    Mentaliste
    Inscrit en
    Mars 2008
    Messages
    872
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Mentaliste
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2008
    Messages : 872
    Par défaut
    Citation Envoyé par philouZ Voir le message
    Perso je n'utilise pas de NoSQL car je n'en ai absolument pas l'utilité. A mon sens le NoSQL ne peut avoir un intérêt que dans l'utilisation du big data avec un volume de donnée extrêmement important et je ne suis pas encore dans ce cas.
    C'est ce raisonnement qu'il faut pousser au maximum : à savoir : surtout, si vous n'avez pas de gros volumes de données, n'utilisez jamais du NoSQL : ça n'a aucun intérêt, et à tous les niveaux, sauf en termes de performance.

  4. #4
    Membre extrêmement actif
    Avatar de dukoid
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2012
    Messages
    2 100
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2012
    Messages : 2 100
    Par défaut
    Citation Envoyé par SurferIX Voir le message
    C'est ce raisonnement qu'il faut pousser au maximum : à savoir : surtout, si vous n'avez pas de gros volumes de données, n'utilisez jamais du NoSQL : ça n'a aucun intérêt, et à tous les niveaux, sauf en termes de performance.
    ça n'a aucun sens ce que tu dis, tu te contraris toi-même.

    n'utilisez jamais du NoSQL ..... sauf en termes de performance.

    donc faut savoir ?

  5. #5
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Billets dans le blog
    9
    Par défaut
    je sais pas si SQL est plus performant que NoSQL, mais dans mon cas le SGBD Cassandra est plus performant que n'importe quels SGBD SQL (Oracle database, PostgreSQL, les autres comme DB2 ou SQL server jamais essayé)

    Je pense pas qu'il faut raisonner en terme de langage (sql ou pas sql) mais en terme de SGBD.

  6. #6
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 693
    Par défaut
    Comparer du relationnel et du nosql en demandant lequel est le meilleur c'est comme comparer une formule 1 et un voiture du Dakar.
    Les deux peuvent rouler vite , chacune dans leur domaine.

    Evidemment que si j'ai un modele de données qui requiert des relations entre les entités , ca serait complètement stupide de partir sur du nosql parce que c'est la mode. Et inversement stocker des données indépendantes avec du relationnel n'est sans doute pas optimum.

    Bref c'est un faux débat
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  7. #7
    Membre actif
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2011
    Messages
    98
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2011
    Messages : 98
    Par défaut Et la réponse les 2 sont bien ça dépend le projet ?
    Il manque simplement une réponse : Les 2 sont super pour qui sait les utiliser à bon escient !

    C'est ridicule de dire que SQL ou NoSQL est mieux... NoSQL c'est une autre philosophie et chercher à les comparer c'est un peu comparer du sel et du sucre. On ne les utilise pas pour les mêmes recettes mais les 2 sont dans l'armoire de la cuisine.

    J'ai été formé sur du SQL avec Oracle donc ce milieu m'est très familier. Pourtant j'ai eu la volonté d'apprendre à utiliser NoSQL et à changer aussi ma façon de pensée car IL FAUT penser différemment en NoSQL qu'en SQL ! Et c'est à mon sens l'erreur la plus fréquente des dev de la vieille école SQL -> ils veulent retrouver les mêmes concepts ! Si je peux faire ça en SQL je veux pouvoir le faire en NoSQL ... c'est pas comme ça ^^ il faut structurer différemment il faut penser différemment.

    Et au final NoSQL est vraiment bien dans des cas adaptés. le NoSQL offre une flexibilité que SQL NE PEUT PAS égaler. En sql on ajoute un champ ca implique des scripts de migrations, des problèmes car "Que fait-on avec les entrées déjà existantes ? on met à null ?"

    En nosql on prend le problème différemment :
    Ok on accepte un objet avec ce nouveau champ sans faire aucune modif dans notre bdd. Et simplement quand on le récupère on fait un petit test si ce champ est défini -> sinon ... et basta

    Juste une autre philosophie

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 983
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 983
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par sbeex Voir le message
    ... En sql on ajoute un champ ca implique des scripts de migrations, des problèmes car "Que fait-on avec les entrées déjà existantes ? on met à null ?"
    Hélas ce genre d'erreur est fréquente, mais ne devrais pas être. En vertu de la règle de modélisation qui dit "PAS DE NULL" dans une base, on ne doit jamais rajouter à une table une nouvelle colonne, sans connaître au préalable toutes les valeurs (ce qui est généralement utopique). La solution est donc de créer une nouvelle table liée à la précédente en modèle d'héritage.
    Ainsi on se retrouve dans la même situation que dans le NoSQL ou si l'information n'y est pas il n'y a pas de stockage, mais avec un avantage sur le NoSQL, c'est que quand on requête sur les données, sauf cette colonnes (donc toutes les requêtes précédemment établies) on ne se farcie pas le poids des nouvelles données !!!

    Dans ce cas le NoSQL est plutôt mauvais...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  9. #9
    Membre actif
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2011
    Messages
    98
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2011
    Messages : 98
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Hélas ce genre d'erreur est fréquente, mais ne devrais pas être. En vertu de la règle de modélisation qui dit "PAS DE NULL" dans une base, on ne doit jamais rajouter à une table une nouvelle colonne, sans connaître au préalable toutes les valeurs (ce qui est généralement utopique). La solution est donc de créer une nouvelle table liée à la précédente en modèle d'héritage.
    Ainsi on se retrouve dans la même situation que dans le NoSQL ou si l'information n'y est pas il n'y a pas de stockage, mais avec un avantage sur le NoSQL, c'est que quand on requête sur les données, sauf cette colonnes (donc toutes les requêtes précédemment établies) on ne se farcie pas le poids des nouvelles données !!!

    Dans ce cas le NoSQL est plutôt mauvais...

    A +
    Oui mais sachant que chaque année environ 2 à 3 nouveaux champs surviennent suite au travail de nos chers business analyst ça veut dire qu'on devrait faire 3 - 4 nouvelles tables, faire donc 3 à 4 jointures en + par an dans toutes nos requêtes sql alors qu'un simple update de la table pourrait suffir ? Je pense que c'est effectivement "propre" mais niveau esthétisme je trouve ça assez reboutant. En plus avec les ORM du style Hibernate en Java cela implique de transformer nos entités en entités hiérarchisées avec des types et de l'héritage juste pour un ou 2 champs supplémentaires.

    Ca me parait un peu "overkill"... PersonneAvecDateDeNaissanceEtAnimalDomestic > extends PersonneAvecDateDeNaissance > extends Personne (au final ca ne veut plus rien dire...)

    Dans ce cas un "NULL" a tout à fait sa place. Je ne vois pas dans quel principe de modélisation on ne devrait pas avoir de valeur nullable... pour gérer un profil utilisateur je m'imagine assez mal rendre tous les champs obligatoire à vrai dire. J'ai certainement mal compris vos propos.

    Je reste à l'écoute ! Merci pour la réponse en tous cas

  10. #10
    Expert confirmé

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 755
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 755
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par sbeex Voir le message
    En sql on ajoute un champ ca implique des scripts de migrations, des problèmes car "Que fait-on avec les entrées déjà existantes ? on met à null ?"
    +1

    LE SQL c'est bien quand on a les idées bien claires de son schéma de données et qu'il ne bouge pas trop. Mais quand on a des données hétérogènes / qui évoluent beaucoup, Dieu que c'est lourd!

    Typiquement sur un projet où il faut indexer des centaines de milliers de fichiers afin de les classer (=> ajout progressif d'information au cas par cas) ben avec Go et MongoDB, je continue d'être enchanté par la productivité que j'ai face à une approche SQL. J'ajoute les infos que j'ai au moment où je les ai sans me préoccuper des données déjà existantes. Et tout ça est en place en 15 minutes sans même me prendre la tête avec un ORM où autre usine à gaz... du bonheur

    Bon après pour ce qui est d'assurer des contraintes d'intégrité ou faire du relationnel, je crois que c'est enfoncer des portes ouvertes de dire que les SGBDR sont meilleurs !

  11. #11
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 983
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 983
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par RyzenOC Voir le message
    je sais pas si SQL est plus performant que NoSQL, mais dans mon cas le SGBD Cassandra est plus performant que n'importe quels SGBD SQL (Oracle database, PostgreSQL, les autres comme DB2 ou SQL server jamais essayé)

    Je pense pas qu'il faut raisonner en terme de langage (sql ou pas sql) mais en terme de SGBD.
    Autrement dit vous dites n'importe quoi sans savoir !

    Sachez qu'il existe de nombreuses circonstances dans lesquels les SGBD relationnels seront bien plus rapide que les SGBD NoSQL. Par exemple pour dédoublonner des informations, le NoSQL a des performances catastrophiques pour retrouver les informations identiques alors qu'en relationne via SQL cela est instantané !
    Un de mes clients dans la téléphonie à payer pour le savoir... Et cher !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  12. #12
    Membre éclairé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juin 2012
    Messages
    80
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2012
    Messages : 80
    Par défaut
    Quel est selon vous le meilleur SGBD : SQL ou NoSQL ?

    Dans 99% du temps le SQL car relationnel. Le NoSQL pour les informations partagées entre ferme de serveur et la très haute performance de flux en temps réel.

    Je peux donner 2 cas d'utilisation de NoSql. Du cache partagé (config/tarif aérien) entre plusieurs serveurs afin de ne réduire la charge et une pile d'information alimenter par les communications de plusieurs opérateurs télécom pour analyse 'en temps réel' (de l'information poubelle, lue puis jetée) où les traitements sont massifs.

    Ces besoins ne se présentent pas tous les jours. Si vous avez d'autres exemples où la contrainte oblige à utiliser du noSQL, envoyez!

  13. #13
    Membre confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2013
    Messages
    106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Bâtiment

    Informations forums :
    Inscription : Avril 2013
    Messages : 106
    Par défaut
    Pour ma part je n'ai eu à faire qu'a des SGDBR classique (DB2, MSSQLS, Sybase ASA).
    J'ai une connaissance assez lointaine du sujet NoSQL mais comme dit précédemment il est difficile de comparer des techno prévu pour des usages différents.

    [troll ON]
    Plutôt pain ou baguette?
    [troll OFF]

  14. #14
    Membre averti Avatar de TheGuit
    Homme Profil pro
    Architecte technique
    Inscrit en
    Juin 2005
    Messages
    33
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : Juin 2005
    Messages : 33
    Par défaut
    Déjà la question est débile de base NoSQL regroupe tellement de concept different ! Si ce monsieur veux m'expliquer que SQL est plus rapide pour gerer des données de session que Redis je veux bien qu'il me le montre. Je suis 100% sur qu'il a tord.

    En NoSQL on retrouve les base clé/valeur, les base object, les base graph, ... On est entrain de comparer des choses incomparable.

    Il y'a une choses qui est très vrai par contre, les gens font souvent le choix NoSQL par effet de mode et sans en comprendre les concepts, comme toujours c'est forcément moyen.

  15. #15
    Membre très actif
    Homme Profil pro
    bricoleur par les mots
    Inscrit en
    Avril 2015
    Messages
    732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 80
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : bricoleur par les mots
    Secteur : Distribution

    Informations forums :
    Inscription : Avril 2015
    Messages : 732
    Par défaut
    ce qui en resort c'es que sql est ancien et de ce fait a corrigé les defaults qu'il a pu avoir et bien évidement sa communauté importante.


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    $gt: new Date(Date.now() - 24*60*60 * 1000)
    il parle de galere pour la conversion de la date mais pas tant que sa il suffit de faire une fonction générique et de creer une librairie direction npm faut bien participé.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    function debut(jour){
     
    new Date(Date.now()-jour*24*60*60 * 1000)
     
    }

  16. #16
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2004
    Messages
    375
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2004
    Messages : 375
    Par défaut
    Citation Envoyé par TheGuit Voir le message
    Déjà la question est débile de base NoSQL regroupe tellement de concept different ! Si ce monsieur veux m'expliquer que SQL est plus rapide pour gerer des données de session que Redis je veux bien qu'il me le montre. Je suis 100% sur qu'il a tord.
    Quels sont tes arguments pour dire que Redis est forcément plus rapide qu'un SGBDR ? Je ne connais pas mais d'après la description faite sur le site web c'est juste une base de données stockée directement sur la RAM, ce que la plupart des SGBDR peuvent faire aussi. Quels sont les avantages de Redis ?

  17. #17
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 983
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 983
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par TheGuit Voir le message
    ... Je suis 100% sur qu'il a tord.
    Vous avez raison sur le fond et tort sur la forme : en effet, "tort" prend un t et non un d... Avec un d final vous êtes "tordu" !
    Sur le fond, effectivement le NoSQL devrait être consacré à des données non structurées comme des emails, des entrées de blogs, des informations d'événements... Certainement pas pour des données qui sont structurées à la base, car sinon vous rentrez dans le problèmes du bruit identifiée dès l'origine de l'informatique par Claude Shannon, qui impose dans ce cas des traitements réactifs pour corriger le bruit (code CRC, redondances de l'info, etc...).
    En sus il convient de spécifier que certains de ces traitements différent selon leur nature et qu'il existe des outils spécifiques pour certaines d'entre eux :
    • réseaux sociaux => base en graphe (par forcément NoSQL et à ce titre Microsoft est en train de préparer une petite révolution)
    • GED => base orienté document
    • événements => CEP (Complex Event Processing, par exemple StreamInsight)



    En NoSQL on retrouve les base clé/valeur, les base object, les base graph, ... On est entrain de comparer des choses incomparable.

    Il y'a une choses qui est très vrai par contre, les gens font souvent le choix NoSQL par effet de mode et sans en comprendre les concepts, comme toujours c'est forcément moyen.
    Vous avez doublement raison et le principal problème du NoSQL est qu'en plus il se cherche, les technologies changent, donc c'est pas stable... Par exemple MongoDB l'une des plus populaire à changé 3 fois de structure de stockage... Bonjour les projets poubelle !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  18. #18
    Membre actif Avatar de sitexw
    Homme Profil pro
    Développeur Web
    Inscrit en
    Février 2015
    Messages
    44
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Février 2015
    Messages : 44
    Par défaut
    Regarde quelques benchmark sur Internet et tu verras tout de suite la différence ! Après, on parle d'un cas assez précis où il est évident que les bases de données SQL non pas l'avantage.
    Pour finir, je pense qu'il faut choisir la bonne technologie au bonne endroit et non pas de mettre tous dans le même sac. Globalement une base de données SQL sera largement efficace pour beaucoup de projets. Et le NoSQL prend tout son intérêt au moment où on enregistre une grande quantité de données pour ensuite les analyser. D'où le terme "Big Data".
    Donc la réponse finale est simple, il faut utiliser les deux (dans la mesure où l'on en a besoin).

  19. #19
    Membre très actif
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Août 2014
    Messages
    476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : Août 2014
    Messages : 476
    Par défaut
    Alors totalement d'accord sur l'ensemble des arguments annoncés car c'est ce que j'ai egalement pu constater sur une appli type (duree du projet : 1 an) pour laquelle on a voulu evaluer tous les arguments enoncés pour justifier qu'une BDD nosql est plus performante qu'une BDD relationnelle classique.

    Au final on est resté sur nos BDD traditionnelles. On a definitivement supprimé l'option de deployer une telle BDD en prod (quand on voit les soucis recents de mongodb). A contraintes equivalentes les BDD traditionnelles n'ont pas a rougir; langage universel et pas barbare (voir mongodb - une horreur).
    il n'y a bien que les devs a qui ca plait parce qu'ils n'ont pas a faire de commandes sql et pousse leur json sans s'interroger sur les perfs etc.
    Du vecu. un leurre, phenomene de mode pour mon retour d'experience. C'est souvent les developpeurs qui poussent a utiliser cette techno ('c'est genial...') et quand tu grattes un peu pour l'aspect admin etc. il n'y a plus personne.
    Sans compte qu'il n'y en a pas 2 qui ont les memes syntaxes. hadoop a la limite me parait plus proche du sql dans la syntaxe. La pire : mongodb

  20. #20
    Futur Membre du Club
    Homme Profil pro
    Technicien réseaux et télécoms
    Inscrit en
    Juillet 2016
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Congo-Kinshasa

    Informations professionnelles :
    Activité : Technicien réseaux et télécoms

    Informations forums :
    Inscription : Juillet 2016
    Messages : 2
    Par défaut
    Pour moi dsoftbbm !
    ce SQL pour ça simplicité !!!

Discussions similaires

  1. Sondage: Quel est selon vous le Meilleur livre sur les systèmes?
    Par Lana.Bauer dans le forum Autres systèmes
    Réponses: 0
    Dernier message: 07/06/2013, 14h29
  2. Débat : Quel est selon vous le Meilleur livre sur la virtualisation ?
    Par Community Management dans le forum Livres
    Réponses: 0
    Dernier message: 07/06/2013, 13h14
  3. Réponses: 0
    Dernier message: 10/08/2010, 15h56
  4. Réponses: 12
    Dernier message: 18/08/2009, 18h12
  5. Quel est selon vous le meilleur AV du marché ?
    Par lavazavio dans le forum Sécurité
    Réponses: 6
    Dernier message: 10/10/2005, 08h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo