+ 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
    Étudiant
    Inscrit en
    août 2011
    Messages
    283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : août 2011
    Messages : 283
    Points : 18 062
    Points
    18 062

    Par défaut Pourquoi je ne suis pas adepte du NoSQL ?

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

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

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

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

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

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

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

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

    Source : Article de Matthew Mombrea

    Et vous ?

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

  2. #2
    Membre averti
    Homme Profil pro
    Inscrit en
    décembre 2011
    Messages
    176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : décembre 2011
    Messages : 176
    Points : 342
    Points
    342

    Par défaut

    Encore une fois le NoSQL n'est pas une solution de remplacement du SQL et n'a jamais eu vocation à l'être, simplement l'attrait d'Amazon, Facebook et autre Google pour ces bases a créé un effet de mode qui a généré beaucoup de "faux besoins" dans l'IT.

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

    Recréer une nouvelle solution qui in fine est plus une évol. de quelque chose d'existant qu'une véritable révolution est assez tendance, résultat on ne sait plus quoi adopter et ça créé de l'instabilité dans les solutions et génère des coûts inutiles.

  3. #3
    Membre averti
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2013
    Messages
    131
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : janvier 2013
    Messages : 131
    Points : 423
    Points
    423

    Par défaut

    De mon point de vue d'étudiant, je pense que NoSQL est une alternative au Relationnel, qui révèle son intérêt dans certains cas précis.

    Je reste convaincu que des systèmes relationnels suffisent amplement pour la plupart des besoins, à condition de choisir le bon SGBD et bien l'utiliser.
    Qui plus est, mais ceci est un avis personnel, je trouve NoSQL plus compliqué à "comprendre".

    Après je pense que SpyServer a utilisé le bon mot : "Effet de mode". Mais il est clair que le NoSQL est à ses débuts et qu'il réserve de bonnes surprises pour le futur. Si son besoin est justifié.

  4. #4
    Provisoirement toléré

    Profil pro
    Inscrit en
    juin 2003
    Messages
    357
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : juin 2003
    Messages : 357
    Points : 0
    Points
    0
    Billets dans le blog
    1

    Par défaut NoSQL sert a rien

    Pour moi le NoSQL ne sert à rien du tout car il repose tout comme les plus des SGBD sur des index implémenté via des BTREE.
    Un SGBD comme oracle peux servir pour tout a condition de bien modéliser le model de donnée et mettre les bon index.

  5. #5
    Membre éclairé
    Ingénieur de recherche
    Inscrit en
    novembre 2008
    Messages
    225
    Détails du profil
    Informations professionnelles :
    Activité : Ingénieur de recherche

    Informations forums :
    Inscription : novembre 2008
    Messages : 225
    Points : 805
    Points
    805

    Par défaut

    Mode caricature : en gros ce qui gène ce monsieur c'est de devoir réfléchir pour choisir la solution adaptée ? :p

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

    Désolé si ça ne lui convient pas, mais si, il faut réfléchir en démarrant un projet, et sur bien d'autres points encore que le choix de base de données.

  6. #6
    Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    juillet 2013
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : juillet 2013
    Messages : 1
    Points : 4
    Points
    4

    Par défaut Not only SQL = NoSQL

    J'avais lu à quelque part qu'il y avait méprise sur le terme même de NoSQL :

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

    Est-ce correct ?

  7. #7
    Membre du Club
    Inscrit en
    février 2005
    Messages
    47
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 47
    Points : 50
    Points
    50

    Par défaut

    Nom : BY3DI37IMAE-yr6.jpg
Affichages : 2019
Taille : 35,8 Ko

  8. #8
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 009
    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 009
    Points : 39 484
    Points
    39 484
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Mouke Voir le message
    De mon point de vue d'étudiant, je pense que NoSQL est une alternative au Relationnel....
    Non, pas du tout ! Et c'est même ce qu'exprime les "auteurs" du NoSQL. Pas une alternative, mais un complément dans les rares cas ou les SGBDR pourraient s'avérer inefficaces...

    De toute façon le No SQL ne survivra pas si :
    1) il n'y a pas un "langage" commun pour manipuler ces bases
    2) on change de technologie régulièrement (ce qui a déjà été le cas de plusieurs outils noSQL obligeant ceux qui avaient développé des applications NoSQL à tout jeter)
    3) les éditeurs actuels de SGBD Relationnel intègrent une partie de noSQL à leurs solutions, ce qui commence à être le cas pour Oracle et SQL Server...

    Donc, à mon avis, dans 5 ou 6 ans, Mongodb comme Cassandra, direction... poubelle! Comme l'ont été les SGBD OO ou les SGBD xml.

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

  9. #9
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    novembre 2004
    Messages
    1 738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 738
    Points : 3 012
    Points
    3 012

    Par défaut

    Que les développeurs apprennent déjà à manipuler et modéliser une base de données relationnelle a peu près correctement avant de basculer (souvent pour de mauvaise raisons) sur du NOSQL.
    Je rappel que le NOSQL n'a pas vocation à réellement améliorer les temps de réponse mais à assurer une montée en charge... ce qui n'est pas tout à fait la même chose.
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  10. #10
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    1 048
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

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

    Informations forums :
    Inscription : septembre 2003
    Messages : 1 048
    Points : 1 617
    Points
    1 617

    Par défaut

    NoSQL = "Not Only SQL"
    Pour info, NoSQL est à l'origine un hashtag twitter. Les interprétations qu'on a donné sont presque toutes fausses : NoSQL = not SQL (en clair : non-relationnel).

    De toute façon le No SQL ne survivra pas si :
    1) il n'y a pas un "langage" commun pour manipuler ces bases
    2) on change de technologie régulièrement (ce qui a déjà été le cas de plusieurs outils noSQL obligeant ceux qui avaient développé des applications NoSQL à tout jeter)
    3) les éditeurs actuels de SGBD Relationnel intègrent une partie de noSQL à leurs solutions, ce qui commence à être le cas pour Oracle et SQL Server...
    1) Le langage commun ne peut exister que si le paradigme est le même. Comment espérer un langage commun entre une base graphe et une base clé valeur (par exemple) ?
    2) Il faut donner aux outils le temps de se stabiliser : les bases relationnelles ne sont pas devenues du jour au lendemain stables, performantes, etc.
    3) Et on voit apparaître des solutions dites NewSQL aussi : en clair, on n'arrête pas le progrès...

    Donc, à mon avis, dans 5 ou 6 ans, Mongodb comme Cassandra, direction... poubelle! Comme l'ont été les SGBD OO ou les SGBD xml.
    Je n'en serai pas si sûr : Google aussi bien que Facebook, Twitter etc. utilisent ce type de solutions depuis une dizaine d'années déjà (pour Google et Amazon au moins). Pour le reste, bien malin qui peut affirmer ce qui va se passer...

    Je rappel que le NOSQL n'a pas vocation à réellement améliorer les temps de réponse
    Tout dépend : certaines bases spécialisées de type clé-valeur, si (Riak est ultra-rapide, par exemple).

    Je conseille la visualisation de cette pour mieux comprendre ce qui se cache derrière ce terme "NoSQL".
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

  11. #11
    Expert confirmé
    Profil pro
    Inscrit en
    août 2008
    Messages
    2 548
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 2 548
    Points : 4 904
    Points
    4 904

    Par défaut

    Tiré du blog :
    To make matters worse, you have to wade through engine-specific documentation to read about how you would accomplish your goals, most of which seem like workaround efforts if you have relational data or would like ACID transactions.
    Ben du coup, le choix semble plutôt simple, non ?
    Par ailleurs stocker des données non relationnelles dans un SGBDR, c'est également souvent de la bidouille.

    Compare that to a relational SQL database where, for the most part, you know how the engine will work regardless of the particular product.
    Vu que justement en fonction du produit le moteur fonctionne différemment (même entre SGBDR MVCC il y a des subtilités), sa remarque est plutôt un total non sens...

  12. #12
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 009
    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 009
    Points : 39 484
    Points
    39 484
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Patriarch24 Voir le message
    1) Le langage commun ne peut exister que si le paradigme est le même. Comment espérer un langage commun entre une base graphe et une base clé valeur (par exemple) ?
    Et c'est bien là le problèmes en multipliant les les langages on divise les application (tiens c'est du Audiard... "Les bénéfices, ça se divise, la réclusion, ça s’additionne !) Bref, les développeurs apprendrons un des langages du NoSQSL ferons tout avec et ça merdera et on en entendra plus parler !
    2) Il faut donner aux outils le temps de se stabiliser : les bases relationnelles ne sont pas devenues du jour au lendemain stables, performantes, etc.
    FAUX : à l'origine des SGBDR une théorie et non pas le bricolage actuel du NoSQL. Une fédération très rapide autour d'un langage (SQL 1974 avant même les premiers SGBDR) et donc une normalisation très rapide (1986)... Ce qui en a fait le succès ! Cela existe t-il dans le noSQL ???
    3) Et on voit apparaître des solutions dites NewSQL aussi : en clair, on n'arrête pas le progrès...
    Vous parliez de technologie mature ??? ;-)

    Je n'en serai pas si sûr : Google aussi bien que Facebook, Twitter etc. utilisent ce type de solutions depuis une dizaine d'années déjà (pour Google et Amazon au moins).
    D'accord mais pour quel usage ? Du blabla, mais rien de concret... Autrement dit pour faire du web documentaire (forums, blogs...), ça va bien. Pou faire des appli de gestion c'est pas du noSQL qui est utilisé !

    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
    Membre habitué

    Profil pro
    Inscrit en
    janvier 2003
    Messages
    65
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 65
    Points : 140
    Points
    140

    Par défaut

    Vision simpliste.

    Les bases NoSQL sont apparues parce que les bases relationnelles ACID classiques ne pouvaient pas répondre aux problématiques (montée en charge, bases hyper-relationnelles, haut volume, disponibilité).
    C'est aussi pourquoi le monde NoSQL est si vaste et hétéroclite, chaque solution a été conçue pour un besoin.


    Quand les SGBD relationnels ACID sauront gérer des petaoctets de données de facon performante, efficacement en termes de stockage, et sans un sharding manuel des données, alors le NoSQL sera bien moins intéressant.

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

  14. #14
    Membre confirmé

    Profil pro
    Inscrit en
    octobre 2003
    Messages
    288
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2003
    Messages : 288
    Points : 451
    Points
    451

    Par défaut

    Citation Envoyé par iolco51 Voir le message
    Vision simpliste.

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

  15. #15
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    novembre 2004
    Messages
    1 738
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 738
    Points : 3 012
    Points
    3 012

    Par défaut

    Citation Envoyé par spidetra Voir le message
    Tu aurais des exemples de bases hyper-relationnelles ? C'est une notion que je ne connais pas.
    Est-ce que tu fait référence aux bases orientés graphes et aux hyper-graphes ?
    Je pense qu'il voulais parler de bases fortement normalisées
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  16. #16
    Membre confirmé

    Profil pro
    Inscrit en
    octobre 2003
    Messages
    288
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2003
    Messages : 288
    Points : 451
    Points
    451

    Par défaut

    Citation Envoyé par iberserk Voir le message
    Je pense qu'il voulais parler de bases fortement normalisées
    Tu parles de la 4° forme normale ? Je n'ai encore jamais croisé un projet qui ai poussé la normalisation jusqu'à cette forme.
    Et, je ne vois pas trop l'apport du NoSql sur ce point. Au contraire, dans le NoSql, au moins dans les bases orientées documents, les données sont peu normalisées, redondantes, et pas relationnelles.
    C'est pour cela que j'avais associé cette notion d'hyper-relationnelle, plutôt aux bases de types graphes.

  17. #17
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    1 048
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

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

    Informations forums :
    Inscription : septembre 2003
    Messages : 1 048
    Points : 1 617
    Points
    1 617

    Par défaut

    FAUX : à l'origine des SGBDR une théorie et non pas le bricolage actuel du NoSQL. Une fédération très rapide autour d'un langage (SQL 1974 avant même les premiers SGBDR) et donc une normalisation très rapide (1986)... Ce qui en a fait le succès ! Cela existe t-il dans le noSQL ???
    Les bases orientées graphe sont basées sur la théorie des graphes, les bases clé-valeurs (peu ou prou toutes les autres) sur les théories des calculs distribués : la plupart des algorithmes utilisés dans ces bases sont issus de théories diverses.
    Encore une fois, la fédération autour d'un langage est possible car dans ce cas on ne traite qu'un paradigme (relationnel). Je ne vois pas en quoi mon assertion est fausse : les systèmes relationnels ne sont pas devenus du jour au lendemain performants, stables, etc, je persiste et signe. Ils ont beau être basés sur une théorie mathématique, il n'empêche qu'en quarante ans les choses ont évoluées...

    D'accord mais pour quel usage ? Du blabla, mais rien de concret... Autrement dit pour faire du web documentaire (forums, blogs...), ça va bien. Pou faire des appli de gestion c'est pas du noSQL qui est utilisé !
    Facebook : utilisation de Cassandra pour le système de messaging, d'une base orientée graphe pour la gestion des liens entre relations, entre autres. Google utilise BigTable et d'autres systèmes pour son moteur de recherche. D'autres utilisent Hadoop pour les traitements massifs de données.

    ps : il n'y a pas que les applications de gestion qui existe. Et même celles-là peuvent utiliser du NoSQL pour fonctionner.

    on divise les application
    L'heure est en effet aux divisions d'applications, et non à l'intégration à l'extrême. Le but : utiliser le bon outil pour une tâche donnée (cf : WOA, micro services, architectures hexagonales etc.). Et la présentation de Martin Fowler est très intéressante aussi.
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

  18. #18
    Membre expérimenté Avatar de nathieb
    Homme Profil pro
    Chef de projet/Architecte
    Inscrit en
    mai 2004
    Messages
    1 031
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet/Architecte
    Secteur : Service public

    Informations forums :
    Inscription : mai 2004
    Messages : 1 031
    Points : 1 460
    Points
    1 460

    Par défaut NoSQL

    Bonjour,

    Je vois avec intérêt que cela déchaine les passions :

    - Je dirais qu'il faut savoir nuancer son avis, j'ai été d'accord sur certains points avec SQLPRO jusqu'a l'essai, et je pense que non, il faut être pragmatique.
    Le NoSQL a de l'avenir, peut être pas sous les solutions que nous connaissons, il faut simplement lui laisser du temps.
    Je travaille sur un projet mi gestion mi BI, et justement dans le cadre du BI, certains atouts du NoSQL sont une vrai plus value au projet.
    - L'utilisation du Map/reduce me permet facilement de mettre a disposition des calculs.
    - il est facile voir trop de faire de la réplication
    - cerise sur le gateau, je peux faire des réplications avec des mini NoSQL embarqué dans le navigateur

    Est ce possible avec un SGBD standard, non ... et c"est dans le domaine du mobile quand retrouve sa force.
    Donc est ce un enemi, non mais un allié, comme toute solution, il est perfectible.
    - Pas de structure (Point fort et Point faible suivent ce qu'on veut)
    - Peu de typage, on fait tout et n'importe quoi ...
    ....

    Cette liberté à un cout d'entré (il bouscule nos fodamantaux SGBD), mais cela en fait sa force.
    On ne peux le nier, l'essayer c'est aussi l'adopter, car ces solutions ont un côté magique
    qui nous libère des lourdeurs d'un gros SGBD, droit, architecture, mais en place etc ...
    d'ou aussi son adoption sur des projets type devops.

    Il suffit de parcourir les forums français, pour observer notre retard dans le domaine, il faut justement que cela
    se développe, et cela commence déjà par les sconsciences, il faut oser. c'est a l'image du cloud, on dix ans de retard
    dans les mentalités et les infrastructures.

    J'avoue je me suis laché ....

    Olivier
    Architecte destructurant,
    be cool, be free

    Il nous reste Debian bien sûr

  19. #19
    Membre expérimenté Avatar de nathieb
    Homme Profil pro
    Chef de projet/Architecte
    Inscrit en
    mai 2004
    Messages
    1 031
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet/Architecte
    Secteur : Service public

    Informations forums :
    Inscription : mai 2004
    Messages : 1 031
    Points : 1 460
    Points
    1 460

    Par défaut

    Citation Envoyé par Patriarch24 Voir le message
    Les bases orientées graphe sont basées sur la théorie des graphes, les bases clé-valeurs (peu ou prou toutes les autres) sur les théories des calculs distribués : la plupart des algorithmes utilisés dans ces bases sont issus de théories diverses.
    Encore une fois, la fédération autour d'un langage est possible car dans ce cas on ne traite qu'un paradigme (relationnel). Je ne vois pas en quoi mon assertion est fausse : les systèmes relationnels ne sont pas devenus du jour au lendemain performants, stables, etc, je persiste et signe. Ils ont beau être basés sur une théorie mathématique, il n'empêche qu'en quarante ans les choses ont évoluées...


    Facebook : utilisation de Cassandra pour le système de messaging, d'une base orientée graphe pour la gestion des liens entre relations, entre autres. Google utilise BigTable et d'autres systèmes pour son moteur de recherche. D'autres utilisent Hadoop pour les traitements massifs de données.

    ps : il n'y a pas que les applications de gestion qui existe. Et même celles-là peuvent utiliser du NoSQL pour fonctionner.


    L'heure est en effet aux divisions d'applications, et non à l'intégration à l'extrême. Le but : utiliser le bon outil pour une tâche donnée (cf : WOA, micro services, architectures hexagonales etc.). Et la présentation de Martin Fowler est très intéressante aussi.
    Tout a fait d'accord avec cette dernière phrase ...

    Olivier
    Architecte destructurant,
    be cool, be free

    Il nous reste Debian bien sûr

  20. #20
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 009
    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 009
    Points : 39 484
    Points
    39 484
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par iolco51 Voir le message
    Vision simpliste.

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


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

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

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

    A +
    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 * * * * *

Discussions similaires

  1. Réponses: 1
    Dernier message: 01/10/2007, 17h32
  2. [W3C] Pourquoi ça ne marche pas sous IE
    Par polo-j dans le forum Balisage (X)HTML et validation W3C
    Réponses: 6
    Dernier message: 16/02/2005, 16h07
  3. Pourquoi je n'ai pas le droit à un bootsplash ?
    Par Michaël dans le forum Administration système
    Réponses: 4
    Dernier message: 30/08/2004, 14h02
  4. [C#] Pourquoi je ne peux pas sauvegarder le fichier Xml ?
    Par gregoun dans le forum Services Web
    Réponses: 5
    Dernier message: 05/05/2004, 10h00

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