+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 3 123 DernièreDernière
  1. #1
    Expert éminent sénior

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    mars 2013
    Messages
    426
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Enseignement

    Informations forums :
    Inscription : mars 2013
    Messages : 426
    Points : 32 461
    Points
    32 461

    Par défaut Base de données relationnelle ou NoSQL, laquelle constitue le meilleur choix ?

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

    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 ?

  2. #2
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    août 2007
    Messages
    267
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 267
    Points : 529
    Points
    529

    Par défaut

    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. #3
    Membre à l'essai
    Inscrit en
    février 2013
    Messages
    9
    Détails du profil
    Informations forums :
    Inscription : février 2013
    Messages : 9
    Points : 17
    Points
    17

    Par défaut

    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".
    Tu es sur? Ici on dirait qu'à la base c'était pas de SQL (No SQL), mais qu'avec l'utilisation ça c'est transformé en Not Only SQL, comme tu le dis. Je ne suis pas sur que cela signifie exactement Not Only SQL.

  4. #4
    Membre averti

    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2013
    Messages
    88
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2013
    Messages : 88
    Points : 444
    Points
    444
    Billets dans le blog
    1

    Par défaut

    Je rejoins Bono_BX pour dire que NoSQL n'est pas du tout la même réponse que SQL, ils se complémentent dans un sens.

    Je travaille sur une application où j'ai des dossiers.
    Un dossier appartient à un client qui a une adresse qui appartient à une zone qui lui est géré par plusieurs entités.
    Mais ce dossier a un type qui n'est géré que pas certaines entités.
    La jointure de ces deux listes entités à partir du dossier doit donner un résultat unique quoi qu'il arrive.
    Qu'on n'aille pas me dire que NoSQL réponds efficacement à cette problématique. J'ai ici besoin d'une structure relationnelle solide.

    Sur cette même application, j'ai des clients avec une tonne d'informations qui sont utiles/renseignées ou pas suivant leur catégorie. Je dois en plus pouvoir chercher sur chacune de ces informations.
    Ici encore, qu'on n'aille pas me dire qu'un SGBDR réponds efficacement à cette problématique. L'aspect déstructuré de mes informations client et les capacités d'indexation qu'offrent des outils comme Solr répondent bien plus efficacement au besoin.

    En bref :
    Êtes-vous un fervent défenseur des bases de données relationnelles ou NoSQL ?
    Les deux.

  5. #5
    Membre confirmé
    Profil pro
    Inscrit en
    mars 2012
    Messages
    305
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2012
    Messages : 305
    Points : 530
    Points
    530

    Par défaut

    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.

  6. #6
    Membre éprouvé Avatar de atha2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    661
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : janvier 2007
    Messages : 661
    Points : 1 143
    Points
    1 143

    Par défaut

    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

  7. #7
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 785
    Points : 9 612
    Points
    9 612

    Par défaut

    À plusieurs reprises je me suis demandé quels étaient les avantages des BDD NoSQL, et j'ai fait quelques recherches.
    Certaines de ces recherches sont assez révélatrices.

    En effet, allez dans Google et tapez "mongodb vs postgresql", c'est particulièrement éloquent.

    Les résultats sont principalement de 2 types :
    1. les gens qui se sont essayés au NoSQL, qui ont dit "plus jamais ça" et qui sont revenus sur du relationnel
    2. les gens qui ont fait des tests de performances entre les 2

    Là aussi, les tests sont très intéressants. La plupart du temps, ils arrivent aux conclusions suivantes :
    - postgres permet de faire du relationnel, mais il permet aussi de faire du non relationnel (stockage de documents en XML ou en JSON, stockage de key/value avec hstore)
    - pour du non relationnel, et avec la bonne configuration, postgres se révèle au moins aussi performant que MongoDB
    - par conséquent, avec postsgres on a le meilleur des 2 mondes : on peut faire du non relationnel avec d'excellentes performantes, et faire du relationnel quand on en a besoin, le tout avec un seul et même outil !
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  8. #8
    Membre averti

    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2013
    Messages
    88
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2013
    Messages : 88
    Points : 444
    Points
    444
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par pcaboche Voir le message
    À plusieurs reprises je me suis demandé quels étaient les avantages des BDD NoSQL, et j'ai fait quelques recherches.
    Certaines de ces recherches sont assez révélatrices.

    En effet, allez dans Google et tapez "mongodb vs postgresql", c'est particulièrement éloquent.

    Les résultats sont principalement de 2 types :
    1. les gens qui se sont essayés au NoSQL, qui ont dit "plus jamais ça" et qui sont revenus sur du relationnel
    2. les gens qui ont fait des tests de performances entre les 2

    Là aussi, les tests sont très intéressants. La plupart du temps, ils arrivent aux conclusions suivantes :
    - postgres permet de faire du relationnel, mais il permet aussi de faire du non relationnel (stockage de documents en XML ou en JSON, stockage de key/value avec hstore)
    - pour du non relationnel, et avec la bonne configuration, postgres se révèle au moins aussi performant que MongoDB
    - par conséquent, avec postsgres on a le meilleur des 2 mondes : on peut faire du non relationnel avec d'excellentes performantes, et faire du relationnel quand on en a besoin, le tout avec un seul et même outil !
    Désolé de mettre en doute les résultats que tu a pu trouver, mais si les comparaisons se font sur la base d'une recherche sur un champ (ou partie précise d'un document) particulier, alors le SGBDR est au moins aussi performant que le moteur non structuré. C'est d'ailleurs une bonne nouvelle car sinon on aurait des questions à se poser.
    L'avantage de la plupart des moteurs NoSQL est leur capacité d'indexation sur le document entier grâce aux différentes implémentations de MapReduce. Là où Postgre va rendre l'âme c'est dans une recherche de type google. Rechercher un ou plusieurs mots parmi des téra-octets de simples textes comme nos réponses sur ce forum avec classification par pertinence.
    Il existe certains modèles relationnels qui permettent d'effectuer ces recherches efficacement par la recherche de mots clés, je n'en doute pas, mais ce n'est pas le but premier d'un SGBDR alors qu'un moteur déstructuré sacrifiera les propriétés ACID d'un SGBD pour te permettre de bonnes performances de recherche.

  9. #9
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2005
    Messages
    227
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Philippines

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

    Informations forums :
    Inscription : octobre 2005
    Messages : 227
    Points : 519
    Points
    519

    Par défaut

    La grande force (mais aussi ça faiblesse) du NoSQL, c'est l'aspect elastique des types de données, qui permet de stocker des informations spécifiques au cas par cas.

    Enfin, moi c'est ce que je ressent. Je trouve le modele HStore de PGSQL pas mal pour ça: une base relationnel avec un champs fourre-tout qui permet d'ajouter des elements à un objet relationnel.

    Après je ne sais pas ce que ça vaut en terme de performance, et la complexité des requetes va en grandissant lors de l'usage d'HStore...

  10. #10
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 212
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 212
    Points : 3 133
    Points
    3 133
    Billets dans le blog
    12

    Par défaut

    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
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  11. #11
    Expert éminent
    Homme Profil pro
    Big Data / Freelance EURL
    Inscrit en
    mars 2003
    Messages
    2 112
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Big Data / Freelance EURL

    Informations forums :
    Inscription : mars 2003
    Messages : 2 112
    Points : 7 287
    Points
    7 287

    Par défaut

    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
    Argl ?! C'est à ce point là ? Ben je préfére le bon vieux SQL.

  12. #12
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 785
    Points : 9 612
    Points
    9 612

    Par défaut

    Citation Envoyé par Grimly Voir le message
    Désolé de mettre en doute les résultats que tu a pu trouver,
    Voici l'une de ces présentations, que j'ai trouvée tres intéressante (j'étais trop fatigué pour la rechercher hier soir) :
    http://www.slideshare.net/stjernstro...gdayfosdem2013

    Parmi les conclusions :
    Vous pouvrrez toujours touver des tâches qui "prouvent" qu'une technologie est la meilleure
    ... y compris pour DBase II
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  13. #13
    Membre éclairé
    Homme Profil pro
    Enseignant
    Inscrit en
    décembre 2007
    Messages
    205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Suisse

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2007
    Messages : 205
    Points : 830
    Points
    830

    Par défaut

    Comme d'autre avant moi dans ce fil, je suis d'avis qu'il n'est pas pertinent de poser la question en ces termes. "Laquelle constitue le meilleur choix ?" ne peut avoir de réponse en dehors de tout contexte, puisque c'est justement ce contexte en lien avec les forces et les faiblesses des différents modèles qui permettra de déterminer laquelle est la plus appropriée. De plus, la réponse ne doit pas forcément être unique, certaines données d'une application peuvent se trouver dans une base de données NoSql alors que d'autres se trouvent dans une base de données relationnelle.

    Si dans une application on remplace un système de gestion de bases de données relationnelles par un système de gestion de bases de données NoSql et qu'on se rend compte que cela n'apporte aucun avantage, que cela nuit aux performances, ou que cela complique le développement, cela ne dit rien ni à propos du NoSql en général ni à propos des SGBDR en général, cela indique seulement que le modèle relationnelle était le plus adapté pour cette application.

    Les bases de données NoSql ont leur domaine d'application. Jamais les modèles NoSql (key-value, column, object, etc.) n'ont eu pour vocation de remplacer le modèle relationnel, il n'ont été développé que pour répondre à des problème auxquelles les SGBDR n'apportaient pas de réponse satisfaisante.

  14. #14
    Membre averti
    Profil pro
    Inscrit en
    décembre 2010
    Messages
    126
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2010
    Messages : 126
    Points : 355
    Points
    355

    Par défaut

    Bonjour,

    Les bases de données no-sql n'ont pas vocation à remplacer les SGBDR classique, mais à remplir des besoins spécifique (en général gagner en scalabilité). D'ailleurs il existe plusieurs types de bases nosql, très différente les unes des autres.

    Voici une page qui donne une comparaison des différentes bases nosql les plus populaire : http://kkovacs.eu/cassandra-vs-mongo...uchdb-vs-redis

  15. #15
    Expert confirmé
    Avatar de pmithrandir
    Homme Profil pro
    Chef d'équipe développement
    Inscrit en
    mai 2004
    Messages
    1 872
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Irlande

    Informations professionnelles :
    Activité : Chef d'équipe développement
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mai 2004
    Messages : 1 872
    Points : 4 055
    Points
    4 055

    Par défaut

    Citation Envoyé par pcaboche Voir le message
    avec postsgres on a le meilleur des 2 mondes : on peut faire du non relationnel avec d'excellentes performantes, et faire du relationnel quand on en a besoin, le tout avec un seul et même outil !
    Il manque un aspect important des base no SQL(ou aussi newSQL), la capacité de faire du sharding.

    Dans la boite ou je travaille, on est en train de tout virtualiser. ca nous fait gagner beaucoup en automatisation, en réactivité et sur les opérations manuelles.
    Le plus gros problème, c'est que la scalabilité en virtuel est horizontale, et non verticale. Si tu as besoin de plus de puissance, tu ajoute une node a un cluster au lieu d'une nouvelle barette de RAM.

    Et la, les solutions oracle, mysql, postgres sont larguées. Seul NoSQL semble capable de faire ca pour le moment, et des truc newSQL comme nuoDB, mais ou l'on a peu de recul.(et peu de modules, comme un connecteur PDO pour php, doctrine, hibernate, etc...)

    Bref, les bases SQL souffrent chez nous à cause de ce simple fait... et on est en train de choisir les solutions noSQl pour de mauvaises raisons.
    Après 9 ans à l'étranger : Canada, Roumanie et Irlande, j'essaye maintenant de rentrer en France en Province.

    Je cherche un poste de manager d'équipe ou de département. J'ai géré jusqu'à 32 personnes et je suis particulièrement intéressé par les structures hiérarchiques "plates" qui encourage à l'autonomie et la communication directe.
    N'hésitez pas à me contacter si vous connaissez un poste correspondant à mon profil.

    Mon profil linked in

  16. #16
    Membre à l'essai
    Homme Profil pro
    Développeur .NET
    Inscrit en
    octobre 2011
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : octobre 2011
    Messages : 5
    Points : 15
    Points
    15

    Par défaut

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

  17. #17
    Nouveau membre du Club
    Profil pro
    Web dev
    Inscrit en
    septembre 2007
    Messages
    16
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Web dev

    Informations forums :
    Inscription : septembre 2007
    Messages : 16
    Points : 25
    Points
    25

    Par défaut A chacun son emploi

    Je rejoins un peu les commentaires précédents précisant qu'il est plus judicieux d'analyser en amont les données qui devront être traitées pour faire le bon choix de SGBD.

    Je fais même l'analogie avec le secteur automobile. Les voitures électriques sont bien présentes mais représentent encore un faible % comparées aux véhicules à moteur thermique. Les 2 types de véhicules cohabitent mais pour l'instant, l'un n'est pas prêt de remplacer l'autre.

    Donc à chacun de voir ce qu'il souhaite en faire comme usage avant de se lancer tête baissée parce que c'est juste à la mode et que les grands groupes l'utilisent.

  18. #18
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 072
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 072
    Points : 19 085
    Points
    19 085
    Billets dans le blog
    17

    Par défaut

    A chaque problème sa solution, il faut arrêter de comparer deux types de stoquage de données aussi différent.
    Un exemple avec twitter qui utuilise les deux : SGBDR (mysql/mariaDb) + noSQL(cassandra)
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  19. #19
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    597
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 597
    Points : 1 039
    Points
    1 039

    Par défaut Raison d'être du NO SQL

    La raison d'être du NoSQL est de créer des bases de données plus rapide que celle SQL en évitant certaines contraintes liés au SQL. Par exemple une base qui ne gère pas de droits d'accès et d'utilisateur gagne peu de temps mais cela peu parfois être utile. De même une base, NoSQL, qui n'a pas comme contrainte la jointure du SQL peut stocker / restituer plus rapidement les données. C'est le cas des bases clé/valeurs. Alors oui on gagne a utiliser du NoSQL si on a pas ces contraintes. Par contre remettre ces contraintes autre part, c'est perdre du temps, c'est réinventer la roue, c'est perdre en sécurité et efficacité (car on aura pas utilisé une méthode éprouvé)...
    Une autre raison du NoSQL c'est de gérer de nouvelles contraintes comme celle des bases graphes. Cela permet de gérer la contrainte de jointure graphique et de résoudre des problème très simplement (Meilleur chemin par exemple) car la solution est intégrer dans la base.
    Il y a des outils meilleurs que d'autres (MariaDB > MySQL > "SQL Server" ) mais il n'y a pas d'outils universel.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  20. #20
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 139
    Points
    2 139

    Par défaut

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

Discussions similaires

  1. Réponses: 29
    Dernier message: 25/04/2014, 10h15
  2. Réponses: 29
    Dernier message: 25/04/2014, 10h15
  3. Réponses: 3
    Dernier message: 22/12/2005, 11h20
  4. Avenir des bases de données relationnelles ?
    Par LordBob dans le forum Décisions SGBD
    Réponses: 53
    Dernier message: 30/10/2005, 23h27
  5. fichiers séquentiels indexés VS base de données relationnell
    Par Clotilde dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 22/08/2005, 06h31

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