Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Décisions SGBD Discussion :

SGBD : le mouvement anti-SQL s’amplifie ?


Sujet :

Décisions SGBD

  1. #21
    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 173
    Points
    2 173
    Par défaut
    Avant tout, il faudrait expliquer où est le problème avec SQL et en quoi ces nouvelles technologies les résolvent.

  2. #22
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 1 214
    Points
    1 214
    Par défaut
    Citation Envoyé par Népomucène Voir le message
    Est-ce que tu peux nous en dire plus sur ton expérience ?
    Voilà mon rapport sur App-Engine

  3. #23
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 1 214
    Points
    1 214
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Avant tout, il faudrait expliquer où est le problème avec SQL et en quoi ces nouvelles technologies les résolvent.
    Très clairement pour Google, c'est une question de scalabilité. Quand tu intervient sur une Bdd au mexique, il faut que le serveur au Japon soit au courant. Et vite.

    Ca n'a sans doute pas été prévu comme cela au départ.

  4. #24
    Membre éprouvé Avatar de Jester
    Inscrit en
    septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : septembre 2003
    Messages : 813
    Points : 1 014
    Points
    1 014
    Par défaut
    J'avais posté quelques liens sur ce thread.

    http://www.developpez.net/forums/d75...s/#post4461616

    Je pense que les SGBDR restent la référence pour faire du transactionnel ACID, mais que pour les autres cas, il y a des solutions plus adéquates.

  5. #25
    Membre confirmé

    Homme Profil pro
    Inscrit en
    août 2006
    Messages
    317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : août 2006
    Messages : 317
    Points : 585
    Points
    585
    Par défaut
    J'ai lu les ressources indiqués à droite et à gauche mais sans vraiment trouver de réponse à ce sujet.

    J'ai trouvé quelques réponses dans cet article concernant le système Dynamo utilisé par Amazone

    Cela ne semble pas être un rejet complet de système des bases de donnée relationnel mais plutôt un système permettant de les découper pour éviter d'utiliser quand ce n'est pas nécessaire un système trop lourd.

    Il s'agirait d'un langage de requête permettant de manipuler plusieurs sources de données adaptés à des usages particulier en permettant l'usage des fonctionnalités standards nécessaire à un code de qualité.

    Pour résumer, ça ressemble à surcouche qui ne rejette en rien les bases de donnée SQL mais l'intégre comme une source de données parmis tant d'autre.

  6. #26
    Membre averti
    Profil pro
    Inscrit en
    février 2008
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : février 2008
    Messages : 131
    Points : 310
    Points
    310
    Par défaut
    Sujet très intéressant.

    De ma petite expérience des outils de mapping relationnels/objets, je me suis souvent rendu compte que pour quelqu'un qui connait bien le SQL, c'est très frustrant, et que l'on est souvent tenté (voire obligé) de faire du SQL pure ( pour des requête de comptage ou pour tester l'existence de relation par exemple).

    Je comprends que les adeptes du tout objet cherchent un moyen de se débarrasser des bases relationnelles, en passant à des bases objets.

    Mais la mayonnaise ne prend pas, et les bases objets ont du mal à percer. Peut être à cause de nous, les informaticiens, un peu trop formaté à MERISE et autre méthodologie d'analyse.

    Le NoSQL, d'après les quelques liens dans les posts, ressemble à si méprendre au cloud computing. Ne pas savoir ou son ses données, ça c'est le pied

    Bref, attendons de voir ce que ça va donner, si un standard (de fait ou non) en ressort.

  7. #27
    Modérateur

    Homme Profil pro
    Développeur java, access, sql server
    Inscrit en
    octobre 2005
    Messages
    2 671
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur java, access, sql server
    Secteur : Industrie

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 671
    Points : 4 642
    Points
    4 642
    Par défaut
    Citation Envoyé par nicorama Voir le message
    Après avoir lu ton compte-rendu, je vais me dépêcher d'attendre ...
    Labor improbus omnia vincit un travail acharné vient à bout de tout - Ambroise Paré (1510-1590)

    Consulter sans modération la FAQ ainsi que les bons ouvrages : http://jmdoudoux.developpez.com/cours/developpons/java/

  8. #28
    Membre éclairé
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    614
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 614
    Points : 677
    Points
    677
    Par défaut
    Citation Envoyé par jpouly Voir le message
    De ma petite expérience des outils de mapping relationnels/objets, je me suis souvent rendu compte que pour quelqu'un qui connait bien le SQL, c'est très frustrant, et que l'on est souvent tenté (voire obligé) de faire du SQL pure ( pour des requête de comptage ou pour tester l'existence de relation par exemple).

    Je comprends que les adeptes du tout objet cherchent un moyen de se débarrasser des bases relationnelles, en passant à des bases objets.
    Oui mais attention, l'utilisation d'outils d'ORM a évidemment un but de construction d'objets et en effet est inadapté à des requêtes "simples". La documentation d'Hibernate par exemple dit explicitement que dans certain cas il vaut mieux passer par du SQL natif.

    Cependant, souvent, on peut observer que beaucoup de traitement sont remontés au niveau des développeurs d'application qui oublient que stockage et traitement des données sont deux choses différentes. C'est ce qui peut être inquiétant lorsqu'on voit ce genre de démarche. Combien de développeurs d'applications ont pris part à ces démarches, combien de gestionnaires de données ? Le premier message met bien en avant l'interrogation et la modification, mais une base de données ne se limite pas à ça. Une alternative à SQL est certes à rechercher, mais sans faire table rase de l'existant.

  9. #29
    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 173
    Points
    2 173
    Par défaut
    Citation Envoyé par nicorama Voir le message
    Très clairement pour Google, c'est une question de scalabilité. Quand tu intervient sur une Bdd au mexique, il faut que le serveur au Japon soit au courant. Et vite.

    Ca n'a sans doute pas été prévu comme cela au départ.
    N'est-on pas en train de vouloir faire faire au SGBD des choses qui ne sont pas de son ressort ?

  10. #30
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    YYYY
    Inscrit en
    mai 2002
    Messages
    19 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : YYYY
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 257
    Points : 45 546
    Points
    45 546
    Par défaut
    Ce mouvement est bien entendu la conséquence désastreuse de la perte de connaissance sur ce que sont les données et l'intérêt des SGBDR en général comme outil central de toute application gérant des données.

    Relisez l'article que j'ai posté sur le développement en base de données épaisse... Bien sur je suis à contre courant. Mais à contre courant du marketing, pas de la technologie....

    Posez vous la bonne question, à savoir d'où vient ce mouvement contestataire ?

    Il est assez simple de constater qu'il vient de deux horizons bien identifiés : ceux qui prônent le tout objet via notamment Java (un langage en perte de vitesse et désormais "acquis" par Oracle à travers Sun) et quelques autres industriels qui préféreraient vous voir plonger dans leurs solutions captives comme Google !

    Quand aux SGBDR "SGBD-attributs/valeurs" ils ont 20 ans de retard. C'est un modèle qui a eu son heure de gloire un peu avant les SGBD relationnels, notamment avec Pick...

    Bref, ce débat c'est Darwwin contre le créationnisme. Un mouvement très en vogue aux US en ce moment !

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

  11. #31
    Membre éclairé Avatar de bassim
    Homme Profil pro
    Ingénieur Réseaux
    Inscrit en
    février 2005
    Messages
    666
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Réseaux
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : février 2005
    Messages : 666
    Points : 687
    Points
    687
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    un langage en perte de vitesse et désormais "acquis" par Oracle à travers Sun
    Wow, affirmer ça avec autant de certitude !! en tout cas, pour contredire cette affirmation, on peut se baser sur le sondage des langages de programmation préférés.

    Et puis en Java, on prône beaucoup plus le mapping Objet/Relationnel que le remplacement de SQL (c'est différent non ?).

    A noter aussi qu'en .net, il y a l'émergence de la technologie LINK.

    Si le SQL n'a pas d'alternative crédible, pourquoi disparaitrait il ?
    Where is my mind

  12. #32
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 929
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 929
    Points : 27 178
    Points
    27 178
    Par défaut
    Si je ne suis pas le raisonnement des anti-SQL, je trouve néanmoins, SQLpro, que tu est gonflé de te poser en seul défenseur de la vérité face à une horde d'escrocs.....

    Mon point de vue : il faut un système pour gérer les données. SQL ou un autre. Sauf que SQL, malgré ses défauts, est standard. Perso, je ne vais pas m'emmmnuyer à faire autre chose, parceque ça n'aurait pas de valeur ajoutée. Mais ça ne fait pas de SQL la panaçée : c'est juste un standard qui convient à peu près.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  13. #33
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    YYYY
    Inscrit en
    mai 2002
    Messages
    19 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : YYYY
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 19 257
    Points : 45 546
    Points
    45 546
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Sauf que SQL, malgré ses défauts, est standard.
    C'est justement ce qui gène fortement les requins aux dents longues qui préféreraient une solution maison et fermée pour vous la vendre et que vous soyez piégés avec pendant des années !!!
    Posez vus la question de savoir combien Google vous fera payer un jour le fait que vos données seront stockées sur ses serveurs et que vous voudriez tout récupérer en local.. Quel sera la coût de cette migration ?
    En règle générale, tous nos joyeux développeurs oublient une seule chose : l'inertie représenté par le volume des données... C'est un facteur très important, largement sous estimé, voire non pris en compte dans les projets !

    Si on ne peut que constater la réussite des SGBD Relationnels, c'est justement par ce que tout cela se base sur deux faits incontournables :
    1) une théorie mathématique jamais encore démentie, même si des "aménagements" ont été réalisé par l'ouverture RO (voir The Third manifesto de Date et Darwen).
    2) un langage normatif, qui, même s'il est "victime" de dialectes est somme toute assez portable car il suffit d'apprendre SQL pour être à l'aise sur n'importe quel SGBDR

    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. #34
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 1 214
    Points
    1 214
    Par défaut
    Je ne vois vraiment pas où il y a débat. J'utilise Hibernate via JPA et je crée ma database en SQL. Ya aucun conflit, les zenfants

    Je ne vois pas comment utiliser un ORM sans connaitre le SQL, quoiqu'il en soit connaitre les deux ne vous rendra jamais plus idiot.

  15. #35
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 766
    Points
    15 766
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Si on ne peut que constater la réussite des SGBD Relationnels, c'est justement par ce que tout cela se base sur deux faits incontournables :
    1) une théorie mathématique jamais encore démentie, même si des "aménagements" ont été réalisé par l'ouverture RO (voir The Third manifesto de Date et Darwen).
    2) un langage normatif, qui, même s'il est "victime" de dialectes est somme toute assez portable car il suffit d'apprendre SQL pour être à l'aise sur n'importe quel SGBDR
    On peut également constater que les SGBD Relationnels ont leurs limites : le typage statique des données, la structure fixe des tables et des contraintes fortes sur les relations. Ces limites apparaissent d'autant plus que la mode est à la "souplesse" dans la manipulation des données.

    Qui ne s'est pas retrouvé à devoir réécrire toutes ses requêtes SQL suite au changement de type d'un champ, ou le split d'une table en plusieurs ?
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  16. #36
    Rédacteur

    Avatar de Erwy
    Homme Profil pro
    Développeur Web
    Inscrit en
    novembre 2003
    Messages
    4 967
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : novembre 2003
    Messages : 4 967
    Points : 11 585
    Points
    11 585
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    C'est justement ce qui gène fortement les requins aux dents longues qui préféreraient une solution maison et fermée pour vous la vendre et que vous soyez piégés avec pendant des années !!!

    Les bases XML (dont je ne crois pas avoir vu de représentant dans la liste des participants de cet manifestation??) s'appuient sur des technologies tout à fait standardise et non propriétaire.

    entre autres:
    XML et XLINK pour les documents et les liaisons
    XML SCHEMA pour le typage et la validation
    XPATH,XQUERY pour l'interrogation et le requêtage

    ces technologies sont de plus très largemment utilisé en dehors du contexte SGBD.

    Les SGBD XML ne sont pas axés non plus sur les mêmes besoins.Les SGBDR étant des données fortement "thématiques" alors qu'une base XML native est généralement plus utilisé dans un axe donnée "documentaire".

    Donc ne pas pas généraliser à toutes les solutions ne s'appuyant pas sur le SQL

  17. #37
    Membre habitué
    Avatar de savageman86
    Profil pro
    Inscrit en
    octobre 2006
    Messages
    105
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : octobre 2006
    Messages : 105
    Points : 197
    Points
    197
    Par défaut
    Citation Envoyé par Thorna Voir le message
    Moi, ce que j'aimerais bien voir, c'est un exemple. Une petite base de test ou de démonstration, comme pour les tutos SQL, et quelques interrogations/ajouts/suppressions/modifications, juste pour avoir une idée de ce à quoi ça peut bien ressembler!
    +1

  18. #38
    Membre à l'essai
    Profil pro
    Inscrit en
    juin 2009
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 12
    Points : 15
    Points
    15
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    N'est-on pas en train de vouloir faire faire au SGBD des choses qui ne sont pas de son ressort ?
    En l'occurrence j'ai compris le contraire. On est en train de vouloir faire faire à d'autres systèmes des choses qui sont du ressort du SGBD.

  19. #39
    Inscrit

    Profil pro
    Inscrit en
    février 2004
    Messages
    862
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : Suisse

    Informations forums :
    Inscription : février 2004
    Messages : 862
    Points : 1 179
    Points
    1 179
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Si on ne peut que constater la réussite des SGBD Relationnels,
    Certes, mais il faut aussi reconnaître la réussite de SGBD Non-relationnels comme BigTable ! La manière de fonctionner de Google et le volume de données traité est une réussite en soit.

    Je trouve néanmoins cette fronde anti-SQL (anti-relationnel par extensions) étrange car il me semble que le couple SGBDR+SQL atteint ses limites sur certains cas et volumétries très très particuliers.

    Partant de là, je vois de la place pour des paradigmes et des langages d'interrogation alternatifs mais aucune raison valable de se passer de SQL.
    In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.

  20. #40
    Membre averti Avatar de _Xavier_
    Profil pro
    Inscrit en
    mai 2009
    Messages
    311
    Détails du profil
    Informations personnelles :
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : mai 2009
    Messages : 311
    Points : 380
    Points
    380
    Par défaut
    Citation Envoyé par Keihilin
    La manière de fonctionner de Google et le volume de données traité est une réussite en soit.
    Au lieu de se limiter à dire que chez Google et chez facebook ça marche bien est ce qu'on peut nous montrer des études théoriques qui évaluent les performances et les limites de ces modèles nonSql, comme c'est le cas avec Sql qui se base sur la théorie des ensembles ?

Discussions similaires

  1. SGBD : le mouvement anti-SQL s’amplifie ?
    Par Annaelle32 dans le forum Actualités
    Réponses: 76
    Dernier message: 17/07/2009, 13h04
  2. [sgbd] lancement de requetes sql
    Par Premium dans le forum SGBD
    Réponses: 3
    Dernier message: 11/11/2006, 17h12
  3. Quel SGBD choisir ? MySQL ou SQL-Server ?
    Par S_H_I dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 13/10/2006, 17h03
  4. [MySQL 5.0] Pb de SGBD et de Requete SQL clause GROUP BY
    Par skyrider dans le forum Langage SQL
    Réponses: 5
    Dernier message: 17/08/2006, 13h24
  5. [sgbd] Ouvrir une base sql
    Par Mu_Belier dans le forum SGBD
    Réponses: 4
    Dernier message: 07/06/2004, 14h05

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