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

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

    30 76,92%
  • NoSQL

    2 5,13%
  • Pas d'avis

    7 17,95%
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 4 1234 DernièreDernière
  1. #1
    Chroniqueur Actualités
    Avatar de Coriolan
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2016
    Messages
    470
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Maroc

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

    Informations forums :
    Inscription : mai 2016
    Messages : 470
    Points : 11 630
    Points
    11 630

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre actif
    Homme Profil pro
    Inscrit en
    mai 2003
    Messages
    152
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Réunion

    Informations forums :
    Inscription : mai 2003
    Messages : 152
    Points : 252
    Points
    252

    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é...
    Philippe,


    N'hésitez à lever le pouce si mon aide vous a été utile.

  3. #3
    Membre expert
    Avatar de RyzenOC
    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    3 307
    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 307
    Points : 3 771
    Points
    3 771
    Billets dans le blog
    8

    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.
    =>Comment jouer sur xbox one à moindre coût ?
    Achetez un notebook de 2010 à 50€ sur leboncoin, installez steam, connectez le pc à un écran, branchez une manette xbox au pc
    Enjoy

  4. #4
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    4 568
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 4 568
    Points : 11 699
    Points
    11 699

    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

  5. #5
    Membre habitué
    Homme Profil pro
    Développeur .NET
    Inscrit en
    juin 2012
    Messages
    74
    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 : 74
    Points : 156
    Points
    156

    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!

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

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

    Informations forums :
    Inscription : septembre 2011
    Messages : 94
    Points : 212
    Points
    212

    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

  7. #7
    Membre actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2013
    Messages
    77
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Nord (Nord Pas de Calais)

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

    Informations forums :
    Inscription : avril 2013
    Messages : 77
    Points : 270
    Points
    270

    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]

  8. #8
    Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2005
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : juin 2005
    Messages : 18
    Points : 48
    Points
    48

    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.

  9. #9
    Membre éclairé
    Homme Profil pro
    chomeur
    Inscrit en
    avril 2015
    Messages
    384
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 72
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : chomeur
    Secteur : Distribution

    Informations forums :
    Inscription : avril 2015
    Messages : 384
    Points : 773
    Points
    773

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

  10. #10
    Membre éclairé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    juin 2004
    Messages
    273
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Belgique

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 273
    Points : 856
    Points
    856

    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 ?

  11. #11
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2015
    Messages
    21
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : février 2015
    Messages : 21
    Points : 45
    Points
    45

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

  12. #12
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 242
    Points : 39 942
    Points
    39 942
    Billets dans le blog
    1

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  13. #13
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 242
    Points : 39 942
    Points
    39 942
    Billets dans le blog
    1

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  14. #14
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 242
    Points : 39 942
    Points
    39 942
    Billets dans le blog
    1

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  15. #15
    Expert éminent

    Profil pro
    tutu
    Inscrit en
    juin 2003
    Messages
    5 591
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : tutu

    Informations forums :
    Inscription : juin 2003
    Messages : 5 591
    Points : 9 654
    Points
    9 654
    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 !

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

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

    Informations forums :
    Inscription : septembre 2011
    Messages : 94
    Points : 212
    Points
    212

    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

  17. #17
    Membre confirmé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Ain (Rhône Alpes)

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

    Informations forums :
    Inscription : août 2014
    Messages : 271
    Points : 457
    Points
    457

    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

  18. #18
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 242
    Points : 39 942
    Points
    39 942
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par sbeex Voir le message
    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
    Encore une fois vous êtes dans l'erreur. Analysons un ajout classique celui de l'ajout du nom marital à une personne.
    Si on ajoute cette colonne à la table on pénalise immédiatement toutes les requêtes existantes qui n'ont jamais pris en compte cette information qui n'existait pas à l'origine de la création, mais doivent lire les octets inutiles du nom marital. Pour rappel même une colonne à NULL coûte des octets que ce soit en VARCHAR ou en CHAR ! Les lecture se faisant à minima sur l'intégralité des données de la ligne, même si ces colonnes ne sont pas pris en compte dans le SELECT !
    Il n'y a donc que de nouvelles requêtes à créer qui prendrons cette information. Et elle seront certainement beaucoup moins nombreuses que les précédentes.
    alors qu'un simple update de la table pourrait suffir ?
    Vous vous trompez, il s'agit d'un ALTER TABLE et ce qui est tragique dans un ALTER TABLE c'est qu'il bloque l'intégralité de la table le temps d'en modifier la structure, ce qui la rend indisponible à toutes requête le temps de procéder à l'ajout de colonne !

    Je pense que c'est effectivement "propre" mais niveau esthétisme je trouve ça assez reboutant.
    En domaine technique l'esthétique on en a rien à faire et il nuit fortement aux performances en général. Or vous me dites que vous voulez comparez les performances du SQL face au NoSQL et vous faites en sorte de démolir sciemment les performances du SQL et faisant des modèles ineptes et imbécile...
    Mauvaise fois ou incompétence ? Je pose la question !

    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.
    Là encore nous savons tous que les ORM sont des machines à tuer les performances et vouloir à tout pris utiliser un ORM montre à quel point il y a encore du boulot en matière d'architecture de données....

    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...
    Le principe n°1 de la modélisation est justement d'éviter les NULL. En particulier en dissociant les attributs propre et les attributs relatifs, les premiers dans l'entité, les autres dans des entités attachées. Cette faute de modélisation qui est la surutilisation du NULL est le premier facteur de dysfonctionnement et de perte des performances des SGBDR !
    Pour information dans la , cette question a largement été débattue et les démonstration de ma part, comme les expérience des personnes présentes ont bien montré le problème !

    ... 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.
    Il serait peut être temps d'apprendre à modéliser correctement !

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  19. #19
    Membre confirmé
    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    décembre 2007
    Messages
    280
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant en Business Intelligence

    Informations forums :
    Inscription : décembre 2007
    Messages : 280
    Points : 565
    Points
    565

    Par défaut

    Bonjour,

    Pour ma part je suis d'accord avec la notion de modélisation qui est primordiale, effectivement cette notion peut sembler laborieuse et difficile a mettre en place, mais elle permet d'apporter une stabilité et des performances plus qu'honorable par la suite si elle est bien pensé au départ !

    Concernant la notion d'ORM d'experience pour avoir été chez des clients qui les utilisaient ( Entity Framework, Hibernate, ... ) j'ai vu plus d'une fois des gros soucis de performance, au point de devoir TOUT reprendre au niveau base de données, creer des procédure stockées et trouver un vrai DBA pour administrer les bases données en gros le temps et le cout projet a été multiplié au moins par 2 du a des erreurs de conception et de modélisation au démarrage.

    A lire l'ensemble de vos poste, vos questions semblent interessantes et vos points de vu sont louables mais il ne faut pas oublier que le No SQL est destructuré et qu'il aura a un moment ou un autre ces limites.

    Perso je le vois comme un gros agrégateur, si j'ai besoin d'analyser des données en grosse maille de manière "brouillion" c'est idéal, mais des qu'on a besoin de mettre de la perfomance et de la rigueur c'est fini et la il faut ajouter une partie relationnel et bien structurer le travail en passant par de la modélisation.

    D'ailleur le principe de BIG DATA chez microsoft repose sur ce principe :

    1. Collecte des informations de manière destructurer dans les différents canaux sources
    2. Filtres des informations nécessaires
    3. normalisation des flux et injection dans un environnement structuré ( SQL Server / Power BI )
    4. Agrégation
    5. Reporting
    MCSA SQL SERVER |MCT | MVP Data Platform

  20. #20
    Modérateur

    Homme Profil pro
    Ingénieur d'études en décisionnel
    Inscrit en
    septembre 2008
    Messages
    7 432
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études en décisionnel
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 432
    Points : 15 715
    Points
    15 715

    Par défaut

    Je pense que grunk a dit l'essentiel. Ce ne sont pas vraiment les mêmes technologies, et même si leur champ d'action peuvent se recouper, elles ne servent pas à la même chose.
    Je rappelle également que NoSQL signifie "Not Only SQL", il ne désire pas remplacer toutes les bases SQL, mais pour les compléter lorsque celles-ci arrivent à des limites, essentiellement de coût et de place.
    Le paradigme généralement associé au bases NoSQL est celui d'une distributivité horizontale : on rajoute des petits serveurs pas trop puissants ni trop cher, et on augmente les performances de manière quasi linéaire.
    Sur les SGBD monolithiques, on met de meilleurs CPU, plus de RAM, de meilleures baies de disques, mais on a la limite de la technologie qui s'impose à un moment.
    L'un et l'autre ont des avantages et des inconvénients.

    Développer une application d'informatique de gestion sur une base NoSQL est très probablement voué à l'échec, tout comme stocker internet sur une base de données locale sur son poste.

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