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é
    Avant tout, il faudrait expliquer où est le problème avec SQL et en quoi ces nouvelles technologies les résolvent.
    J'appelle "Point Traroth" le moment dans une discussion où quelqu'un parle des Bisounours. A partir de ce moment, toute discussion sérieuse devient impossible, puisque la légitimité d'une des parties pour exposer son point de vue est mise en cause. C'est juste un anathème, un moyen de décrédibiliser les autres sans avoir à discuter.

  2. #22
    En attente de confirmation mail
    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
    Robusta Code : Formation - Architecture - Création - Open Source

    Robusta Code

  3. #23
    En attente de confirmation mail
    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.
    Robusta Code : Formation - Architecture - Création - Open Source

    Robusta Code

  4. #24
    Membre éprouvé
    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é
    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
    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

    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/cour...eloppons/java/

  8. #28
    Membre éclairé
    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é
    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 ?
    J'appelle "Point Traroth" le moment dans une discussion où quelqu'un parle des Bisounours. A partir de ce moment, toute discussion sérieuse devient impossible, puisque la légitimité d'une des parties pour exposer son point de vue est mise en cause. C'est juste un anathème, un moyen de décrédibiliser les autres sans avoir à discuter.

  10. #30
    Rédacteur

    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  11. #31
    Membre éclairé
    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
    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

    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  14. #34
    En attente de confirmation mail
    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.
    Robusta Code : Formation - Architecture - Création - Open Source

    Robusta Code

  15. #35
    Rédacteur

    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

    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é
    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
    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
    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
    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 ?

###raw>template_hook.ano_emploi###