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

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    juin 2016
    Messages
    769
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 769
    Points : 22 721
    Points
    22 721

    Par défaut Nous pouvons faire mieux que SQL qui présente quelques lacunes

    Nous pouvons faire mieux que SQL qui présente quelques lacunes,
    selon Elvis Pranskevichus

    La taille des données traitées par les entreprises augmente chaque jour et le Big Data est en plein essor. Les entreprises sont aujourd’hui à la recherche de solutions plus rapides, plus sécurisées et plus optimales pour manipuler toutes ses données. À cet effet, le SQL (Structured Query Language) est depuis plusieurs décennies le langage le plus utilisé pour accéder aux bases de données, mais pour certains, cela ne signifie pas nécessairement que le SQL représente le meilleur de ce que nous pouvons faire. Selon une analyse que propose Elvis Pranskevichus sur le langage de traitement de données, le langage SQL destiné aux requêtes ad hoc possédait dès le départ un bagage de problèmes graves.

    Le langage SQL peut être considéré comme le langage d'accès normalisé aux bases de données. Il est aujourd'hui supporté par la plupart des produits commerciaux que ce soit par les systèmes de gestion de bases de données micro tel que Access ou par les produits plus professionnels tels que Oracle, mais beaucoup commencent à juger que le langage SQL est de plus en plus inadapté pour la manipulation des nouveaux types de données que l’homme est en train de générer depuis quelques années maintenant. L’exemple premier qu’ils donnent est celui des données générées par les médias sociaux (les données audio, vidéo, et.) qui sont des données dites non structurées. L’alternative qu’utilisent certaines entreprises à ce niveau est d’analyser ces données à l’aide d’une base de données NoSQL.

    De son côté et en se basant sur des tests réalisés avec PostgreSQL, Elvis Pranskevichus a essayé de regrouper les lacunes du langage SQL en quatre catégories. Il cite notamment le manque d’orthogonalité appropriée de SQL (SQL est difficile à composer), son manque de compacité (SQL est un langage volumineux), son manque de cohérence (SQL est incohérent dans la syntaxe et dans la sémantique) et sa mauvaise cohésion avec le système c’est-à-dire que le langage SQL ne s'intègre pas assez bien avec les langages et les protocoles d'application. Certaines de ces plaintes présentées ci-dessus, dit-il, concernent SQL dans son ensemble, tandis que d'autres sont spécifiques à une implémentation donnée.

    Nom : z1.png
Affichages : 5485
Taille : 321,9 Ko

    Il a expliqué que l'orthogonalité dans un langage de programmation signifie qu'un ensemble relativement petit de constructions primitives peut être combiné de manière relativement réduite. Un langage avec une bonne orthogonalité est plus petit, plus cohérent et plus facile à apprendre, car il existe peu d'exceptions à l'ensemble des règles. Inversement, une mauvaise orthogonalité conduit à un langage large avec de nombreuses exceptions et mises en garde. Un bon exemple d'orthogonalité dans un langage de programmation est la possibilité de substituer une partie arbitraire d'une expression par une variable, ou un appel de fonction, sans aucun effet sur le résultat final. En SQL, a-t-il indiqué, une telle substitution générique n’est pas possible, car il existe deux types d’expressions incompatibles.

    D’après lui et les propos de Pablo Atzeni, professeur à l’université de Rome et chercheur en base de données, le manque de compacité du langage SQL vient du fait que sa standardisation ou sa normalisation appartient en grande partie aux fournisseurs de bases de données, et non aux chercheurs universitaires sans intérêts commerciaux ou aux utilisateurs ayant des intérêts d'utilisateurs. Un exemple qu’il a donné par rapport à cela est que l'implémentation de PostgreSQL contient 469 mots-clés. La partie 2 seule (sur 14) de la norme SQL:2016 comprend 1732 pages. Il poursuit en disant que l’une des raisons principales à la prolifération de mots clés dans le langage est qu’on veuille faire en sorte qu’il soit adapté aux “non-professionnels”.

    « La raison principale est que SQL, conformément à ses objectifs initiaux, s'efforce d'être un langage de type anglais, adaptée aux « non-professionnels ». Cependant, avec la croissance du langage, cette verbosité a contribué négativement à la capacité d'écrire et de comprendre les requêtes SQL. Nous avons appris cette leçon avec COBOL et le monde a depuis longtemps adopté des langages de programmation plus récents et plus succincts », a-t-il déclaré. Il entame par la suite sa critique sur le manque de cohérence du langage dans sa syntaxe et sa sémantique en disant que cela aggrave encore plus les choses, c'est que différentes bases de données ont leur propre version de SQL, souvent incompatible avec d'autres variantes de SQL.

    À cela, un internaute a déclaré ce qui suit : « Je ne suis pas en désaccord avec le fait que SQL peut encore être amélioré. C'est l'une des principales raisons pour lesquelles j'utilise PostgreSQL en premier lieu, car de nombreuses améliorations sont disponibles en plus de SQL. Cela dit, SQL est sacrément efficace. En tant que langage, c'est la véritable colonne vertébrale d'Internet aujourd'hui. Il est lisible, explicite, assez concis et traduit naturellement la manière dont les données doivent être décomposées pour un stockage efficace et permettre une récupération plus efficace. Il existe des différences entre les implémentations de différents fournisseurs, mais cela sert à trouver des solutions à des défauts d’implémentations chez les autres fournisseurs et les améliorer pour créer un meilleur produit. Je souhaite bonne chance aux gens dans leur travail pour améliorer les choses, mais le langage sur lequel je me suis appuyé régulièrement ces dernières années est le SQL et j'ai travaillé avec beaucoup de langages. SQL est celui qui exécute le plus correctement et me laisse le moins souvent tomber ».

    Nom : z1.png
Affichages : 5314
Taille : 89,2 Ko
    Elvis Pranskevichus

    Selon Pranskevichus, ces différentes faiblesses que présente le SQL nuisent à l’ergonomie des différentes applications. L'orthogonalité, la compacité et la cohérence, a-t-il fait remarquer, sont les caractéristiques essentielles d'un langage de programmation facile à apprendre et à utiliser efficacement à tous les niveaux d'expertise, de taille d'équipe et de complexité du projet. Pour finir avec les critiques, il évoque le fait que le mouvement NoSQL est né en partie de la frustration suscitée par la stagnation et l’insuffisance perçues des bases de données SQL.

    Pour remédier à ces différents soucis que pose le SQL que nous connaissons, ce que propose Pranskevichus est de parvenir à créer une meilleure version de SQL pour les utilisations futures et pouvoir manipuler les données de demain à bon escient. Sa solution à lui, c’est EdgeQL, un langage qui, selon lui, met l'accent sur la convivialité, la performance sans compromettre l'exactitude et résout l’ensemble des problèmes précités. D’après la documentation proposée à l’outil, EdgeDB est une base de données relationnelle-objet qui stocke et décrit les données sous forme d'objets fortement typés et leurs relations. La documentation précise qu’EdgeDB est construit sur PostgreSQL, héritant de toutes ses forces principales : conformité ACID, performances et fiabilité.

    La base de données EdgeDB disposerait des caractéristiques suivantes : schéma strict et fortement typé, possède un langage de requête propre et puissant, permet de travailler facilement avec des données hiérarchiques complexes et propose un support intégré pour les migrations de schéma. La documentation de l’outil renseigne également qu’EdgeDB n'est pas une base de données graphique, les données sont stockées et interrogées à l'aide de techniques de base de données relationnelle. Contrairement à la plupart des bases de données graphiques, EdgeDB maintient un schéma strict. Il est aussi écrit qu’EdgeDB n’est pas une base de documents, mais insérer et interroger des données hiérarchiques de type document est une tâche triviale. L’autre chose qu’on peut noter également est qu’EdgeDB n’est pas une base de données objet traditionnelle. Malgré la classification, précise la documentation, il ne s’agit pas d’une implémentation de la persistance POO (programmation orientée objet).

    « SQL a commencé avec l'objectif de permettre aux non-programmeurs de travailler efficacement avec les données relationnelles. Malgré ses faiblesses, il a sans doute eu un succès retentissant, la plupart des bases de données l'implémentant ou le reproduisant. Cependant, comme toute solution, SQL est confronté à une insuffisance croissante dans la prise en charge des nouvelles exigences, des nouveaux modes d’utilisation et de la productivité des utilisateurs. Il est temps que nous agissions », a conclu Elvis Pranskevichus.

    Source : Billet de blog

    Et vous ?

    Qu'en pensez-vous ?
    Êtes-vous de l'avis de Elvis Pranskevichus ?
    Pensez-vous qu'EdgeQL puisse remplacer le SQL ? Pourquoi ?

    Voir aussi

    AlaSQL.js, une base de données SQL JavaScript pour le navigateur et Node.js, est désormais disponible et serait rapide et très flexible

    La version 5.3.2 de DBeaver, l'outil de base de données multiplateforme, est disponible, tour d'horizon des principales nouveautés

    Google lance Cloud Firestore, une base de données de documents NoSQL sans serveur, serait-elle meilleure que Firebase ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre régulier
    Homme Profil pro
    Lycéen
    Inscrit en
    août 2018
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 16
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : Lycéen

    Informations forums :
    Inscription : août 2018
    Messages : 36
    Points : 104
    Points
    104

    Par défaut

    Nous pouvons faire mieux que html surtout.

  3. #3
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 696
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 696
    Points : 6 041
    Points
    6 041

    Par défaut

    Je suis très étonné de voir cet article (je parle de l'original) en 2019. La tendance 'NoSQL' initiée par ceux qui n'ont pas compris/appris SQL (comme l'auteur le l'article) n'a pas duré longtemps. Aujourd'hui, toutes les solutions alternatives reviennent au SQL, que ce soit pour le BigData ou l'OLTP (exemple: Spark, Kafka, Spanner,...). On voit bien l'incomprehension (sur le language et le relationnel) de l'auteur de l'article dans ses exemples 'orthogonalité'. Vouloir remplacer une variable 'scalar expression' par 'table expression' c'est comme confondre une variable avec un tableau d'enregistrements...
    Et proposer une base de donnée 'relationnelle-objet' en 2019... c'est idée révolutionnaire des années 80! Aujourd'hui, les bases de données objet sont mortes, et les extensions relationnel-object' jamais utilisées.
    Mais le résumé est très bien. C'est sur l'article de Elvis Pranskevichus et l'idée de EdgeQL que je suis très sceptique...
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  4. #4
    Membre éclairé

    Homme Profil pro
    Ingénierie logistique
    Inscrit en
    janvier 2013
    Messages
    249
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénierie logistique
    Secteur : Transports

    Informations forums :
    Inscription : janvier 2013
    Messages : 249
    Points : 657
    Points
    657

    Par défaut

    Citation Envoyé par pachot Voir le message
    ...
    Joli analyse.
    Je trouve que - ou plutôt je cherche à comprendre pourquoi - SQL a une lacune immense : il est pas du tout utilisé en OLAP, en BI, bref en analyse sérieuse des données.
    Pour un langage qui s'appelle search query, et dont le sous-ensemble le plus solide, mature, standard, est le Data Query Language, c'est quand même un comble!
    Ca fait un moment que je me demande si ce n'est pas lié au fait que les big brains, Codd, Date... ont écarté les logiques d'ordre supérieur...
    Empreinte PGP - pool.sks-keyservers.net : 5589 3CA6 6518 1E59 9FCA A48D 2B11 B467 46B3 1D66
    Je suis les règles de Crocker.

  5. #5
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 696
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 696
    Points : 6 041
    Points
    6 041

    Par défaut

    Citation Envoyé par MaximeCh Voir le message
    Pour un langage qui s'appelle search query
    Non. 'Structured Query Language', pas 'Search'. C'est un language structuré (=qui suit la sémantique des opérations d'algèbre relationnelle) qui est utilisé pour toute définition et manipulation de donnée. Avec deux déclinaisons: pour programmer (curseurs, bind variables,...) et pour utilisation ad-hoc par l'utilisateur final - exactement la BI.
    Citation Envoyé par MaximeCh Voir le message
    SQL a une lacune immense : il est pas du tout utilisé en OLAP, en BI, bref en analyse sérieuse des données.
    Alors là je ne comprend pas d'où vient cette idée. Justement, l'indépendance entre le modèle physique et logique, et le fait que ce soit un language déclaratif (l4G) sont les clés la clé de son utilisation en BI. Avec un language procédural (l3G) on doit connaitre à l'avance comment vont être interrogées les données, pour coder l'accés. Avec un L4G, comme SQL, on décrit seulement le résultat et l'optimiseur construit le plan d'exécution (procédural) pour aller chercher les données.

    SQL:2003 définit les functions analytiques (window function) et la plupart des SGBD les implémentent aujourd'hui. C'est la clé de la BI. Toute la BI aujourd'hui utilise SQL. Soit par des SGBD relationnels qui l'ont depuis toujours, soit par les nouveaux Big Data qui l'ont adopté. Faire du code procédural pour analyser des données non structurées n'est efficace que pour un use-case donné. Les requêtes ad-hoc c'est toujours le domaine de SQL.

    Je suis curieux de savoir d'où vient cette idée que SQL n'est "pas du tout utilisé en OLAP, en BI".
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  6. #6
    Membre éclairé

    Homme Profil pro
    Ingénierie logistique
    Inscrit en
    janvier 2013
    Messages
    249
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénierie logistique
    Secteur : Transports

    Informations forums :
    Inscription : janvier 2013
    Messages : 249
    Points : 657
    Points
    657

    Par défaut

    Citation Envoyé par pachot Voir le message
    Non. 'Structured Query Language', pas 'Search'.
    Oulà oui, pas réveillé...
    Citation Envoyé par pachot Voir le message
    SQL:2003 définit les functions analytiques (window function) et la plupart des SGBD les implémentent aujourd'hui. C'est la clé de la BI. Toute la BI aujourd'hui utilise SQL. Soit par des SGBD relationnels qui l'ont depuis toujours, soit par les nouveaux Big Data qui l'ont adopté. Faire du code procédural pour analyser des données non structurées n'est efficace que pour un use-case donné. Les requêtes ad-hoc c'est toujours le domaine de SQL.

    Je suis curieux de savoir d'où vient cette idée que SQL n'est "pas du tout utilisé en OLAP, en BI".
    Les window functions font du bien au langage c'est sûr.
    Dans toutes les boîtes où j'ai travaillé, on m'a asséné qu'on faisait pas de BI en SQL, parce que SQL ne gère pas les (hyper)cubes, (et que de toutes façons il fallait utiliser M$ PowerBI).
    Bon c'est sûr dans ces entreprises, même à la DSI, il n'y avait pas de génies de l'informatique, mais il doit y avoir un fond de vérité...
    Edit : deux liens, cubes OLAP et MDX.

    Edit 2: Pour résumer ce que j'ai vu, le SQL est utilisé pour extraire des ERP, xMS, APS &co vers un datawarehouse, et ensuite les outils/langages dédiés prennent le relai.
    Empreinte PGP - pool.sks-keyservers.net : 5589 3CA6 6518 1E59 9FCA A48D 2B11 B467 46B3 1D66
    Je suis les règles de Crocker.

  7. #7
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 168
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 168
    Points : 7 426
    Points
    7 426
    Billets dans le blog
    43

    Par défaut

    Sceptique par ce EdgeSQL. A vouloir améliorer le SQL, ce qui est toujours louable dans les intentions, on finit toujours par ajouter une nième variante à SQL ce qui est la plaie quand il s'agit de bosser sur des systèmes hétérogènes avec des SGBDR différents.

    Le SQL a ses lacunes, mais quand je vois que beaucoup ont du mal avec la simple approche relationnelle, le EdgeSQL à vouloir faire quelque chose de compact et d'élégant (ce qu'il est peut-être, je n'ai lu qu'en diagonal les exemples), me semble complètement hors de portée intellectuellement parlant pour les développeurs sous-payés et sous-formés à qui on demande de pisser de la requête à l'arrache.

    En résumé, bien tenté, mais aucune chance de percer.
    Tutoriels et FAQ TypeScript

  8. #8
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    910
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 910
    Points : 2 716
    Points
    2 716

    Par défaut

    Citation Envoyé par yahiko Voir le message
    . A vouloir améliorer le SQL, ce qui est toujours louable dans les intentions, on finit toujours par ajouter une nième variante à SQL
    ça me fait un peu penser à cet strip d'XKCD :

    Nom : standards.png
Affichages : 3665
Taille : 23,7 Ko

  9. #9
    Membre éclairé
    Inscrit en
    janvier 2006
    Messages
    331
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 331
    Points : 889
    Points
    889

    Par défaut

    Citation Envoyé par Bill Fassinou Voir le message
    Un bon exemple d'orthogonalité dans un langage de programmation est la possibilité de substituer une partie arbitraire d'une expression par une variable, ou un appel de fonction, sans aucun effet sur le résultat final. En SQL, a-t-il indiqué, une telle substitution générique n’est pas possible, car il existe deux types d’expressions incompatibles.
    C'est vrai que les expressions de type WITH sont arrivées assez tardivement et que même maintenant qu'elles sont là, elles restent difficiles à écrire et verbeuses.
    Un exemple de requête difficile à exprimer en SQL alors qu'elle est facile en langage humain: renvoyer tous les résultats de la requête R1, ou tous les résultats de la requête R2 si et seulement si la requête R1 n'a aucun résultat. Ce qui est très utile par exemple pour faire des compromis: genre, R1 = recherche de termes exacts et R2 = recherche de termes approchants (uniquement si la recherche exacte n'a rien donné)

    Citation Envoyé par Bill Fassinou Voir le message
    « La raison principale est que SQL, conformément à ses objectifs initiaux, s'efforce d'être une langue de type anglais, adaptée aux « non-professionnels ». Cependant, avec la croissance du langage, cette verbosité a contribué négativement à la capacité d'écrire et de comprendre les requêtes SQL. Nous avons appris cette leçon avec COBOL
    C'est vrai que par beaucoup d'aspects SQL me fait penser à COBOL: par exemple quand on regarde les types de données avec un nombre de chiffres plutôt qu'un nombre de bits. Heureusement qu'on n'a plus à se farcir les packed-decimal, manquerait plus que ça.

    Citation Envoyé par Bill Fassinou Voir le message
    Pour remédier à ces différents soucis [...] Sa solution à lui, c’est EdgeQL
    Intéressant, c'eut été encore mieux de mettre au moins un lien dans l'article pour qu'on puisse comparer. Surtout que dans l'original en anglais, il semble bien y avoir des exemples. Bon je vais chercher et étudier ça de plus près, difficile de se faire un avis sinon.

    Citation Envoyé par pachot Voir le message
    La tendance 'NoSQL' initiée par ceux qui n'ont pas compris/appris SQL (comme l'auteur le l'article) n'a pas duré longtemps.
    C'est cela, oui...
    C'est surtout que les communicants des grands vendeurs de bases SQL n'ont pas tardé à réagir et à faire croire aux décideurs des grandes entreprises qu'ils pouvaient faire la même chose. De toute façon les décideurs de grandes entreprises écoutent toujours en priorité ceux qui sont déjà leurs fournisseurs (contrairement aux startups, qui ont au moins le mérite de réellement s'intéresser à la technique)

    Vous vous rappelez des bases de données objet, de l'organisation ODMG?
    A l'époque, les experts SQL ont réussi à faire croire à tout le monde que ce modèle était plus lent que le leur. En réalité, quand on examinait les benchmarks, on se rendait compte que ceux-ci comparaient une base SQL spécialement optimisée pour le problème à résoudre avec un modèle objet écrit par un étudiant qui ne savait pas encore vraiment ce qu'était une classe. Les dés étaient donc pipés dès le départ.
    Résultat:
    1. Même l'extension objet de SQL, dite relationnelle-objet ou SQL 3, bien qu'il s'agisse du dernier standard officiel, est encore passablement ignorée de la plupart des DBA. Il m'est déjà arrivé de venir avec un modèle SQL 3 pour un projet et de le voir converti par le DBA qui n'y comprenait rien...
    2. Comme entre temps les langages comme Java ont fini par supplanter Cobol, mais que les DBA ne veulent pas de SQL 3, on a fini par se retrouver avec des saloperies genre Hibernate (désolé mais même si je suis développeur et pas DBA, je comprends quand même suffisamment le modèle pour voir au premier coup d’œil que les requêtes générées par Hibernate sont non seulement pas optimisées mais probablement pas optimisables non plus...)


    Citation Envoyé par pachot Voir le message
    Aujourd'hui, toutes les solutions alternatives reviennent au SQL, que ce soit pour le BigData ou l'OLTP (exemple: Spark, Kafka, Spanner,...)
    Évidemment, les promoteurs de SQL ont su comment réagir: en créant d'abord un type XML, puis JSON. Maintenant je suis sûr qu'on va voir fleurir les bases SQL avec une seule table ayant un seul champ de type JSON (je caricature à peine)

    Sauf que si tu connaissais vraiment aussi bien NoSQL que tu prétends connaître SQL, tu saurais que le typage fort - qui n'est plus pertinent quand les données sont trop hétérogènes - n'était qu'une partie du problème auquel NoSQL essaie de répondre. Je n'ai par exemple jamais vu de base SQL répartie qui accepte de sacrifier la cohérence pour la rapidité, ce qui est parfois utile (parfois je préfère recevoir rapidement une donnée un peu ancienne que d'attendre que toutes les bases aient été rafraichies pour être sûr d'avoir la plus récente).

  10. #10
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 696
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 696
    Points : 6 041
    Points
    6 041

    Par défaut

    Citation Envoyé par esperanto Voir le message
    Un exemple de requête difficile à exprimer en SQL alors qu'elle est facile en langage humain: renvoyer tous les résultats de la requête R1, ou tous les résultats de la requête R2 si et seulement si la requête R1 n'a aucun résultat. Ce qui est très utile par exemple pour faire des compromis: genre, R1 = recherche de termes exacts et R2 = recherche de termes approchants (uniquement si la recherche exacte n'a rien donné)
    presque une traduction mot à mot du language humain:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
    with 
    "recherche exacte" as (
      select * from DEMO where TEXT='SQL'
      ), 
    "recherche approximative" as (
      select * from DEMO where TEXT like '%SQL'
      )
    select * from "recherche exacte" R1
    union all
    select * from "recherche approximative" R2
    where (select count(*) from "recherche exacte")=0
    ;
    exemple: http://sqlfiddle.com/#!4/d5818/3
    Regarde le plan d'exécution: le full scan n'est exécuté que si la recherche exacte, via index, n'a rien trouvé. On ne peut pas faire plus optimal.

    Sur les SGBDOO et le NoSQL, je crois plus à un point de vue pragmatique performance/consistence/agilité plutôt qu'un complot des éditeurs. Et sur le "typage fort qui n'est plus pertinent..." on en reparle quand dans 10 ans quand il faudra scanner les données hétérogènes pour trouver ce qui ressemble à un nom pour raison GDPR ou à un numéro de carte bancaire pour raison de sécurité. Oh, et "les types de données avec un nombre de chiffres plutôt qu'un nombre de bits" ils sont indispensable pour compter sans erreur d'arrondi, parce que les humains et les banquiers ne comptent pas en bits, et aiment bien les comptes justes. Les startups peuvent partir sur du NoSQL pour compter les likes, mais ils n'ont pas mis leur ERP sur MongoDB
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  11. #11
    Membre éclairé
    Inscrit en
    janvier 2006
    Messages
    331
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 331
    Points : 889
    Points
    889

    Par défaut

    Citation Envoyé par pachot Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
    with 
    "recherche exacte" as (
      select * from DEMO where TEXT='SQL'
      ), 
    "recherche approximative" as (
      select * from DEMO where TEXT like '%SQL'
      )
    select * from "recherche exacte" R1
    union all
    select * from "recherche approximative" R2
    where (select count(*) from "recherche exacte")=0
    ;
    J'ai dit difficile, pas impossible. Dans ton expression on a quand même 4 "select *", ça pourrait être fastidieux si on devait énumérer les mêmes champs à chaque fois... surtout que UNION ALL impose une structure identique, ce qui montre bien que ce serait bien de factoriser.

  12. #12
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 696
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 696
    Points : 6 041
    Points
    6 041

    Par défaut

    Citation Envoyé par esperanto Voir le message
    J'ai dit difficile, pas impossible. Dans ton expression on a quand même 4 "select *", ça pourrait être fastidieux si on devait énumérer les mêmes champs à chaque fois... surtout que UNION ALL impose une structure identique, ce qui montre bien que ce serait bien de factoriser.
    Ah. Je ne vois pas dans quel language ce pourrait être plus simple. Tout en garantissant la cohérence des données, la performance, la lisibilité, l'indépendance de l'implémentation physique,... Le nombre de select peut être réduit, mais c'est beaucoup mieux de séparer chaque composant si on doit rajouter des filtres plus complexes, et des commentaires, et tester un partie individuellement... Et il n'y a aucune raison d'énumérer les colonnes à chaque fois. Une fois est suffisant.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  13. #13
    Membre éclairé
    Inscrit en
    janvier 2006
    Messages
    331
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 331
    Points : 889
    Points
    889

    Par défaut

    Citation Envoyé par pachot Voir le message
    Ah. Je ne vois pas dans quel language ce pourrait être plus simple.
    En fait pour cette requête en particulier il manque juste à SQL un opérateur "short circuit or", capable d'évaluer la seconde opération si et seulement si la première n'a pas suffi à décider. Peut-être pas dans le where, mais au moins en alternative au UNION ALL.
    Évidemment tu vas trouver mille et une raisons pour lesquelles ça ne pourrait pas marcher, mais je crois que ce devrait être à l'optimiseur de requêtes de reconstituer la série de 4 select à partir d'une expression factorisée.

  14. #14
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 696
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 696
    Points : 6 041
    Points
    6 041

    Par défaut

    Citation Envoyé par esperanto Voir le message
    En fait pour cette requête en particulier il manque juste à SQL un opérateur "short circuit or", capable d'évaluer la seconde opération si et seulement si la première n'a pas suffi à décider. Peut-être pas dans le where, mais au moins en alternative au UNION ALL.
    Évidemment tu vas trouver mille et une raisons pour lesquelles ça ne pourrait pas marcher, mais je crois que ce devrait être à l'optimiseur de requêtes de reconstituer la série de 4 select à partir d'une expression factorisée.
    Oui, on peut l'écrire avec in OR si on préfère et l'optimiseur fera OR EXPANSION pour le transformer en UNION ALL. Et l'optimiseur fait ce "short circuit" - cf. l'opération FILTER dans le plan d'exécution Oracle.
    Tout ça existe dans le language SQL. son utilité est justement de ne pas avoir à spécifier commect ce sera exécuté, mais seulement décrire le résultat que l'on cherche. Et l'optimiseur se charge d'écrire le plan d'exécution.

    C'est finalement une très bonne illustration de la puissance de SQL et du relationnel par rapport aux langages procéduraux et aux modèles hierarchiques comme OO/XML/JSON.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  15. #15
    Membre expérimenté
    Profil pro
    Inscrit en
    janvier 2011
    Messages
    1 635
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 635
    Points : 1 613
    Points
    1 613

    Par défaut

    Les normes SQL sont allégrement bafoué : entre du SQL SAS , SQL MySQl , SQL Access , SQL Oracle .

    Un group_concat chez MySQL ? On va proposer un proc transpose chez SAS ! Une fonction VBA usine à gaz sur Access ...

    Ne parlons pas des inner join / join et des diezes gauche ou droite avec les anciennes normes de chez Oracles. L'histoire du top ou du limit aussi est pas mal.

    Chaque société a décidé de plus ou moins faire ses propres normes. Résultat chacun a pris le SQL avec ces normes à lui . Penser que tout changer ou harmoniser est possible ... est illusoire.

    Lier 2 tableaux avec des join est plus facile que de faire boucler un tableau de 2 millions d'enregistrements sur un tableau de 1 millions d'enregistrement . Imaginez le nombre de combinaisons à tout comparer O.O

  16. #16
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 971
    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 : 18 971
    Points : 44 567
    Points
    44 567

    Par défaut

    Citation Envoyé par esperanto Voir le message
    C'est vrai que les expressions de type WITH sont arrivées assez tardivement et que même maintenant qu'elles sont là, elles restent difficiles à écrire et verbeuses.
    Un exemple de requête difficile à exprimer en SQL alors qu'elle est facile en langage humain: renvoyer tous les résultats de la requête R1, ou tous les résultats de la requête R2 si et seulement si la requête R1 n'a aucun résultat. Ce qui est très utile par exemple pour faire des compromis: genre, R1 = recherche de termes exacts et R2 = recherche de termes approchants (uniquement si la recherche exacte n'a rien donné)
    Vous trouvez cela difficile ? Moi pas :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    WITH
    R1 AS (SELECT ...),
    R2 AS (SELECT ...)
    SELECT * FROM   R1
    UNION ALL
    SELECT * FROM   R2 
    WHERE  NOT EXISTS(SELECT * FROM R1)

    Encore une fois il s'agit d'apprendre le SQL !

    A +

    PS pour information c'est un exercice que je donne à mes stagiaires en cours avancé de SQL...
    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 * * * * *

  17. #17
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 971
    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 : 18 971
    Points : 44 567
    Points
    44 567

    Par défaut

    Citation Envoyé par tanaka59 Voir le message
    Les normes SQL sont allégrement bafoué : entre du SQL SAS , SQL MySQl , SQL Access , SQL Oracle .

    Chaque société a décidé de plus ou moins faire ses propres normes.
    ...
    Non, justement ce ne sont pas des normes, ni des standards, mais des dialectes.
    Note que Oracle qui étais il y a encore quelques années, le plus indiscipliné, comble son retard :
    • COALESCE à la place DE NVL
    • CAST en remplacment des TO_...
    • CASE pour DECODE
    • L'arrivée des COLLATIONS, des noms longs et de l'opérateur APPLY….



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

  18. #18
    Membre éclairé

    Homme Profil pro
    Ingénierie logistique
    Inscrit en
    janvier 2013
    Messages
    249
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénierie logistique
    Secteur : Transports

    Informations forums :
    Inscription : janvier 2013
    Messages : 249
    Points : 657
    Points
    657

    Par défaut

    Bump si quelqu'un a la réponse à mon léger HS... ça fait des mois/des années que je cherche à comprendre
    Empreinte PGP - pool.sks-keyservers.net : 5589 3CA6 6518 1E59 9FCA A48D 2B11 B467 46B3 1D66
    Je suis les règles de Crocker.

  19. #19
    Modérateur

    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    7 849
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 849
    Points : 15 585
    Points
    15 585

    Par défaut

    Citation Envoyé par esperanto Voir le message
    Je n'ai par exemple jamais vu de base SQL répartie qui accepte de sacrifier la cohérence pour la rapidité, ce qui est parfois utile (parfois je préfère recevoir rapidement une donnée un peu ancienne que d'attendre que toutes les bases aient été rafraîchies pour être sûr d'avoir la plus récente).
    C'est bien le fond du problème. La cohérence c'est l'acidité des transactions, le rafraîchissement de bases c'est autre chose (copie, backup, peu importe).
    La cohérence n'est jamais sacrifiable car c'est l'enfer de redresser une base incohérente (entrepôt de données à part).

    Quant à la rapidité, je suis chez Teradata depuis deux ans environ et on est "challengé" par les architectures NoSQL qui sont "gratuites".
    Chez le client où j'interviens régulièrement, à volume et cluster physique équivalent (250 To / 8 noeuds), Teradata répond de 10 à 2000 fois plus vite tout en gérant 15 fois plus de charge.
    Tous les PoC volumineux (500 Go de données) commencés sur le cluster hadoop finissent toujours chez nous, car en terme de fonctionnalité, de langage, de rapidité, rien ne tient la route côté NoSQL.

    C'est surtout ça la réalité du NoSQL, une fausse promesse portée par des développeurs (souvent issu du monde Java) qui savent à peine se servir d'une base de données.
    Les performances du cluster hadoop sont justes correctes quand on est seul mais s'effondrent dès qu'il y a un peu de concurrence (et je parle de 10, pas de 5000).

    Je ne dis pas que tout est à jeter, en terme de stockage décentralisé à bas coût c'est une bonne solution.
    Faire du "schema on read" a aussi son utilité ici ou là.
    Mais le travail caché derrière NoSQL est simplement gigantesque : la promesse de réduction de coût n'est jamais tenue.

  20. #20
    Modérateur

    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    7 849
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 849
    Points : 15 585
    Points
    15 585

    Par défaut

    Citation Envoyé par MaximeCh Voir le message
    Dans toutes les boîtes où j'ai travaillé, on m'a asséné qu'on faisait pas de BI en SQL, parce que SQL ne gère pas les (hyper)cubes, (et que de toutes façons il fallait utiliser M$ PowerBI).
    Je fais de la BI depuis une vingtaine d'années, je peux vous dire que cette histoire de cubes OLAP c'est la grande escroquerie de la BI.
    Notoirement poussé par MS car SQL-Server car au début des années 2000 SQL-Server c'était vraiment pas folichon.

    Je suis intervenu dans beaucoup de sociétés différentes, avec des bases sur SQL-Server, de l'Oracle, du PostgreSQL, du Greenplum, du Teradata, de 50 Go à 300 To.
    Les seuls qui font des cubes sont les clients SQL-Server.

    Ceux qui ont d'autres bases n'en ont pas besoin, un datamart étoile / flocon bien modélisé et bien implémenté fait très bien le job.

Discussions similaires

  1. Faire une requete sql qui affiche les ip actifs
    Par Gghizlane dans le forum PHP & MySQL
    Réponses: 4
    Dernier message: 15/09/2016, 10h58
  2. [Javascript] IE(page qui ne s'affiche pas alors que code html présent)
    Par Woufeigh dans le forum Général JavaScript
    Réponses: 6
    Dernier message: 16/04/2007, 19h54
  3. [dBase]il y a mieux que la commande sql UPDATE ?
    Par sana72 dans le forum Autres SGBD
    Réponses: 4
    Dernier message: 12/12/2002, 11h59

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