IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Langage SQL Discussion :

SQL : en l'absence des MAJ importantes depuis des décennies, des critiques appellent à un remplacement


Sujet :

Langage SQL

  1. #1
    Chroniqueur Actualités
    Avatar de Bruno
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2019
    Messages
    1 024
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2019
    Messages : 1 024
    Points : 20 776
    Points
    20 776
    Par défaut SQL : en l'absence des MAJ importantes depuis des décennies, des critiques appellent à un remplacement
    SQL : en l'absence des MAJ importantes depuis des décennies, des critiques appellent à un remplacement du langage,
    par PRQL ou Malloy

    Le SQL (Structured Query Language) est un langage permettant de communiquer avec une base de données. Ce langage informatique est notamment très utilisé par les développeurs web pour communiquer avec les données d’un site web. Toutefois, Carlin Eng, ancien ingénieur en données et responsable de l'ingénierie chez Strava estime que, « à part une poignée de mises à jour de la norme ANSI, le cœur du langage SQL ne s’est pas amélioré après quatre décennies. »

    « SQL est toujours la principale interface utilisateur par laquelle la plupart des professionnels des données interagissent avec leurs systèmes. Les technologies sous-jacentes se sont améliorées de façon incommensurable, mais à part une poignée de mises à jour de la norme ANSI, le cœur du langage reste intact. C'est pratiquement un miracle qu'après plus de 40 ans d'utilisation par d'innombrables professionnels des données, SQL, l’interface avec les données, reste effectivement la même », déclare Carlin.

    Nom : sql.jpg
Affichages : 58597
Taille : 11,0 Ko

    Carlin Eng est un ancien ingénieur en données et responsable de l'ingénierie chez Strava ; il a passé deux ans comme ingénieur commercial et scientifique des données chez Snowflake. Il est actuellement responsable de l'ingénierie des données chez Eppo. Selon Carlin, depuis la création du SQL, de nombreux informaticiens et chercheurs en bases de données ont exprimé leur dédain pour le langage, et leurs critiques sont généralement fondées ; cependant, toutes les tentatives sérieuses de le remplacer comme norme de facto ont échoué.

    La plupart des tentatives de remplacement de SQL portent essentiellement sur ce que Carlin appelle « la syntaxe maladroite du langage », par exemple en plaçant la clause FROM en premier ou en supprimant la nécessité des clauses HAVING et QUALIFY. Malheureusement, la réalité est que SQL est « suffisamment bon » pour la plupart des cas d'utilisation, et selon la loi d'Aiken, la formation des programmeurs est le coût dominant pour un langage de programmation.

    De l’avis de Carlin, les professionnels des données devraient se tourner vers Malloy, un nouveau langage d'interrogation pour l'analyse des données. « Malloy répond à de nombreux problèmes de conception qui affectent SQL, mais le plus intéressant à mon avis est l'intégration d'un langage d'interrogation et d'une couche sémantique en un seul langage. »

    Nom : malloy2.jpg
Affichages : 6488
Taille : 17,1 Ko

    Malloy est un langage expérimental pour décrire les relations et les transformations de données. Développé par Lloyd Tabb, fondateur et ancien directeur technique de Looker, Malloy est à la fois un langage de modélisation sémantique et un langage d'interrogation qui exécute des requêtes contre une base de données relationnelle. Il se connecte actuellement à BigQuery et Postgres, et supporte nativement DuckDB. Une extension Visual Studio Code a été construite pour faciliter la conception de modèles de données Malloy, l'interrogation et la transformation de données, et la création de visualisations et des tableaux de reporting simples.

    Pour essayer l'extension VSCode de Malloy

    1. Téléchargez Visual Studio Code : Télécharger Visual Studio Code ;
    2. Ajoutez l'extension Malloy (pre-release) à partir du marché Visual Studio Code : Ouvrez VS Code et cliquez sur le bouton Extensions à l'extrême gauche (il ressemble à 4 blocs dont un s'envole). Cela ouvrira les extensions. Recherchez Malloy et, une fois trouvé, cliquez sur Installer ;
    3. Téléchargez et décompressez les modèles d'échantillons (modèles + données) ;
    4. Ouvrez le dossier samples dans VS Code. Dans VS Code, allez dans Fichier > Ouvrir le dossier... sélectionnez samples/duckdb > Ouvrir. DuckDB est intégré dans l'extension, vous êtes donc prêt à les exécuter ;
    5. Commencez avec 1_airports.malloy dans l'ensemble de données FAA. Il s'agit d'un sous-échantillon de l'ensemble de données NTSB Flights. Dans le panneau de l'éditeur, au-dessus de source : airports, cliquez sur le mot "Preview" pour exécuter un SELECT *, et cliquez sur le mot "Run" au-dessus de n'importe quel objet de requête pour l'exécuter (voir le gif ci-dessous par exemple).

    Nom : malloy.gif
Affichages : 6500
Taille : 400,5 Ko

    Actuellement, l'extension Malloy fonctionne sur les machines Mac, Linux et Windows

    Voici un exemple simple d'une requête Malloy

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    query: table('malloy-data.faa.flights') -> {
      where: origin ? 'SFO'
      group_by: carrier
      aggregate:
        flight_count is count()
        average_flight_time is flight_time.avg()
    }
    En SQL, ce serait :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    SELECT
       carrier,
       COUNT(*) as flight_count,
       AVG(flight_time) as average_flight_time
    FROM `malloy-data.faa.flights`
    WHERE origin = 'SFO'
    GROUP BY carrier
    ORDER BY flight_count desc         -- malloy automatically orders by the first aggregate

    Malloy : langage de modélisation sémantique

    Etant donné que nos systèmes informatiques ne se conforment pas toujours à la réalité, couche sémantique vient codifier la logique spécifique à un domaine au-dessus des tables de la base de données, et empêcher les utilisateurs d'émettre des requêtes qui sont syntaxiquement valides, mais sans signification sémantique.

    Dans l’exemple présenté par Carlin, le cas de l’écriture d’une jointure entre deux tables dont les clés sont incorrectes, étant donné que dans la plupart des bases de données relationnelles, les clés primaires et étrangères sont simplement des chaînes de caractères ou des chiffres, certaines bases de données peuvent appliquer l'intégrité référentielle, mais la plupart ne poseront aucun souci si vous tentez de joindre, par exemple, CUSTOMER_ID avec ORDER_ID.

    Autre exemple, il arrive souvent que les colonnes de clés primaires soient des nombres entiers, et les bases de données vous laisseront volontiers les utiliser comme entrées pour toute fonction d'agrégation qui prend un nombre en entrée, comme SUM ou AVG, même si le résultat est absurde. Enfin, chaque organisation a des règles spéciales qui doivent être appliquées à ses ensembles de données afin de calculer correctement les indicateurs clés.

    Malloy pourrait-il finalement être le langage qui remplace SQL ?

    Si la question du remplacement du langage SQL ne se pose pas pour certains, il n’en reste pas moins vrai qu’il existe des candidats sérieux à ce remplacement du langage SQL. Malloy pourrait être significativement différent « et plus utile » en raison de son inclusion d'une couche sémantique dans le langage de base. Cependant, en fouillant un peu, on verra qu’il existe également PRQL (Pipelined Relational Query Language) qui est plus intuitif et plus simple, selon l’avis de certains utilisateurs.

    « C'est une tâche presque impossible pour Malloy, mais j'espère vraiment qu'il réussira. Contrairement aux autres projets qui ne cherchent qu'à améliorer l'esthétique du langage, Malloy adopte une approche plus ambitieuse et s'attaque à une pièce manquante critique de la pile », déclare Carlin.

    Son mariage entre le langage de requête et la couche sémantique a le potentiel de changer radicalement les disciplines de l'analyse et de la veille stratégique pour le mieux. D'autres tendances, comme la montée en puissance et la domination de quelques produits de plateforme de données, à savoir BigQuery et Snowflake, pourraient signifier que pour que Malloy réussisse vraiment, il doit prendre en charge relativement peu de cibles de base de données.

    PRQL est un langage moderne pour transformer les données. Pour certains, il s’agit d’un remplaçant simple, puissant et pipeliné de SQL. Comme SQL, il est lisible, explicite et déclaratif. Contrairement à SQL, il forme un pipeline logique de transformations, et supporte des abstractions telles que les variables et les fonctions. Il peut être utilisé avec n'importe quelle base de données qui utilise SQL, puisqu'il se transpose en SQL.

    PRQL peut être aussi simple que :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    from employees
    filter country == "USA"                       # Each line transforms the previous result.
    aggregate [                                   # `aggregate` reduces column to a value.
      max salary,
      min salary,
      count,                                      # Closing commas are allowed :)
    ]

    Voici un exemple plus complet de ce langage :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    from employees
    filter start_date > @2021-01-01               # Clear date syntax.
    derive [                                      # `derive` adds columns / variables.
      gross_salary = salary + (tax ?? 0),         # Terse coalesce
      gross_cost = gross_salary + benefits_cost,  # Variables can use other variables.
    ]
    filter gross_cost > 0
    group [title, country] (                      # `group` runs a pipeline over each group.
      aggregate [                                 # `aggregate` reduces each group to a row.
        average gross_salary,
        sum_gross_cost = sum gross_cost,          # `=` sets a column name.
      ]
    )
    filter sum_gross_cost > 100000                # Identical syntax for SQL's `WHERE` & `HAVING`.
    derive id = f"{title}_{country}"              # F-strings like python.
    sort [sum_gross_cost, -country]               # `-country` means descending order.
    take 1..20                                    # Ran
    Sources : Malloy, Carlin Eng's blog, PRQL

    Et vous ?

    Cette analyse sur le remplacement du langage SQL est-elle pertinente ?

    Partagez-vous l'avis selon lequel le SQL serait obsolète et nécessiterait une MAJ ?

    Quel langage de requête utilisez-vous ? SQL, PRQL ou Malloy ?

    Êtes-vous pour ou contre le remplacement de SQL par PRQL ou Malloy ? Selon vous, est-ce possible ?

    Voir aussi :

    YDB, une base de données SQL distribuée et open source, sous licence Apache 2.0, elle fonctionne sur des plateformes x86 64 bits avec un minimum de 8 Go de RAM

    Il y'aurait plus de mille milliards de bases de données SQLite en utilisation active, faisant du SGBD le composant logiciel le plus largement déployé et utilisé

    SQLite 3.37 est disponible, le moteur de base de données léger apporte le mode STRICT tant attendu, une amélioration de l'interface CLI et plus

    PostgreSQL aurait commencé à travailler sur le support de la compression Zstandard, pour compléter toutes les possibilités de LZ4 que l'on trouve actuellement dans PostgreSQL 14

    Facebook explique les défis auxquels il a dû faire face lors de la migration de MySQL 5.6 vers la version 8.0, une migration qui a duré des années avec à la clé des gains non négligeables
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre chevronné
    Homme Profil pro
    Ingénieur avant-vente
    Inscrit en
    septembre 2020
    Messages
    429
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur avant-vente

    Informations forums :
    Inscription : septembre 2020
    Messages : 429
    Points : 1 874
    Points
    1 874
    Par défaut
    Je préfère largement la syntaxe du SQL aux alternatives proposées. Et pour les fonctionnalités manquantes, on a PL/pgSQL qui fait très bien le taff.

  3. #3
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 772
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 772
    Points : 32 376
    Points
    32 376
    Billets dans le blog
    3
    Par défaut
    Hum...

    Citation Envoyé par Bruno Voir le message
    SQL : en l'absence des MAJ importantes depuis des décennies, des critiques appellent à un remplacement du langage
    "Des" c'est à minima 2, or, la dernière version de SQL est celle de 2016, on pourra donc éventuellement en reparler en 2036

    Par ailleurs, remplacer SQL pourquoi ? Quelles sont les choses qu'on ne peut pas faire correctement avec SQL ?
    Quand on maîtrise ce langage, je dirai pas grand chose. Les critiques viennent souvent d'un défaut de maîtrise de SQL ou d'une utilisation à contre emploi.

    De plus, le patrimoine applicatif est tel qu'un changement de langage aurait un coût monstrueux.

    Je crois au contraire que SQL a encore de beaux jours devant lui

  4. #4
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    juin 2009
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 1 243
    Points : 4 087
    Points
    4 087
    Par défaut
    Citation Envoyé par Bruno Voir le message

    La plupart des tentatives de remplacement de SQL portent essentiellement sur ce que Carlin appelle « la syntaxe maladroite du langage »
    Donc ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    query: table('malloy-data.faa.flights') -> {
      where: origin ? 'SFO'
      group_by: carrier
      aggregate:
        flight_count is count()
        average_flight_time is flight_time.avg()
    }
    est sensé être moins maladroit que ça ?

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    SELECT
       carrier,
       COUNT(*) as flight_count,
       AVG(flight_time) as average_flight_time
    FROM `malloy-data.faa.flights`
    WHERE origin = 'SFO'
    GROUP BY carrier
    ORDER BY flight_count desc         -- malloy automatically orders by the first aggregate

    Et bien j'en conclu que la maladresse n'est pas une notion universelle ^^

  5. #5
    Membre à l'essai
    Homme Profil pro
    développeur sénior
    Inscrit en
    septembre 2012
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : développeur sénior

    Informations forums :
    Inscription : septembre 2012
    Messages : 9
    Points : 24
    Points
    24
    Par défaut
    le principal grief que je pourrais avoir sur le SQL, c'est l'ordre des blocs.

    En toute logique, on devrait avoir :

    FROM
    WHERE
    GROUP
    ORDER
    SELECT

    En regardant bien, c'est ce que les "nouveaux" langages et les ORM font.

    Si SQL pouvait faire de même, pas besoin de plus

  6. #6
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    1 262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 1 262
    Points : 4 498
    Points
    4 498
    Par défaut
    Si le SQL n'a pas subi de MAJ importantes depuis des décennies, c'est tout simplement parce que le SQL répond pleinement aux attentes de ses utilisateurs!!!!!!!!!!!!!!!!


    Sortir l'argument "il faut remplacer parce que pas modifier depuis longtemps" est juste idiot!

    Mais bon, l'idiot en question a obtenu ce qu'il voulait: faire parler de lui.

    De ex-ingénieur, il deviendra dans quelques jours "ex-mec qui a fait parlé de lui pendant une semaine avant de sombrer dans l'anonymat qu'il n'aurait jamais du quitter"

  7. #7
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    juin 2009
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 1 243
    Points : 4 087
    Points
    4 087
    Par défaut
    Citation Envoyé par psancho Voir le message
    le principal grief que je pourrais avoir sur le SQL, c'est l'ordre des blocs.

    En toute logique, on devrait avoir :

    FROM
    WHERE
    GROUP
    ORDER
    SELECT

    En regardant bien, c'est ce que les "nouveaux" langages et les ORM font.

    Si SQL pouvait faire de même, pas besoin de plus

    Le SQL essaye de se rapprocher d'un langage naturel, et je trouve que l'ordre que tu propose ne s'applique ni au français, ni à l'anglais.

    Si tu vas voir un guichet de la SNCF, tu dis un truc du genre "J'aimerais les horaires de départ des trains qui vont à Marseille", ce qui fait un truc du genre "Select departure_time, from connections where destination = `Marseille`", et pas "Des trains qui partent à Marseille j'aimerais les horaires de départ" comme tu le propose.

    La même chose en anglais donne "When do the next trains to Liverpool leave?" avec en premier la demande qui correspond au select (when), le "quoi" ensuite (on cherche des trains) et enfin la particularité en dernier.

    Je veux bien entendre que lors de l'utilisation de requêtes plus complexe avec having, group by etc, l'ordre est moins évident, mais de mon point de vue d'utilisateur occasionnel et plutôt limité du SQL, l'ordre "Select from where" est bon.

    Ceci dit, je pense que tu as raison, il y aurait peut être un moyen technique de rendre le SQL insensible à l'ordre des clauses, comme ça, tout le monde serait content.

  8. #8
    Expert confirmé
    Homme Profil pro
    Responsable informatique, développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    969
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique, développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 969
    Points : 5 005
    Points
    5 005
    Par défaut
    A la maison j'utilise le même marteau depuis plus de 40 ans
    Malgré quelques clous plantés de travers force est de constater qu'il convient toujours aussi bien

    Je devrais le remplacer par quoi ? une clé à molette, une banane en mousse ?

  9. #9
    Membre à l'essai
    Homme Profil pro
    Développeur .NET
    Inscrit en
    octobre 2014
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2014
    Messages : 6
    Points : 16
    Points
    16
    Par défaut
    Citation Envoyé par AoCannaille Voir le message
    Le SQL essaye de se rapprocher d'un langage naturel, et je trouve que l'ordre que tu propose ne s'applique ni au français, ni à l'anglais.

    Si tu vas voir un guichet de la SNCF, tu dis un truc du genre "J'aimerais les horaires de départ des trains qui vont à Marseille", ce qui fait un truc du genre "Select departure_time, from connections where destination = `Marseille`", et pas "Des trains qui partent à Marseille j'aimerais les horaires de départ" comme tu le propose.

    La même chose en anglais donne "When do the next trains to Liverpool leave?" avec en premier la demande qui correspond au select (when), le "quoi" ensuite (on cherche des trains) et enfin la particularité en dernier.

    Je veux bien entendre que lors de l'utilisation de requêtes plus complexe avec having, group by etc, l'ordre est moins évident, mais de mon point de vue d'utilisateur occasionnel et plutôt limité du SQL, l'ordre "Select from where" est bon.

    Ceci dit, je pense que tu as raison, il y aurait peut être un moyen technique de rendre le SQL insensible à l'ordre des clauses, comme ça, tout le monde serait content.
    Commencer par le from a l'avantage que dans les lignes suivantes il peut proposer l'autocomplétion.
    Quand tu commences par select on ne sait pas d'où vont provenir les données donc pas possible de proposer la liste des colonnes possible afin de faciliter l'écriture de la requête.

    Pour faire beaucoup de C# avec VS, l'autocomplétion est vraiment géniale et c'est frustrant quand tu écris une requête SQL pour avoir l'autocomplétion il faut d'abord écrire le from sur la 2e ligne puis tu peux écrire ton select sur la 1ere ligne pour qu'il te propose les colonnes de la table que tu as indiqué dans le from.

  10. #10
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    juin 2009
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 1 243
    Points : 4 087
    Points
    4 087
    Par défaut
    Citation Envoyé par x_x_x_o Voir le message
    Commencer par le from a l'avantage que dans les lignes suivantes il peut proposer l'autocomplétion.
    Quand tu commences par select on ne sait pas d'où vont provenir les données donc pas possible de proposer la liste des colonnes possible afin de faciliter l'écriture de la requête.

    Pour faire beaucoup de C# avec VS, l'autocomplétion est vraiment géniale et c'est frustrant quand tu écris une requête SQL pour avoir l'autocomplétion il faut d'abord écrire le from sur la 2e ligne puis tu peux écrire ton select sur la 1ere ligne pour qu'il te propose les colonnes de la table que tu as indiqué dans le from.
    Mouais, bof comme argument. En SQL, sauf erreur de ma part, la syntaxe "select nom_table.nom_champs from nom_table" est valide. à partir de là, l’autocomplétion devrait directement fonctionner un fois tapé "select nom_table." . Et si ce n'est pas le cas, c'est un manque de fonctionnalité de l'éditeur, pas du langage...

  11. #11
    Membre à l'essai
    Homme Profil pro
    Développeur Java
    Inscrit en
    juin 2022
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : juin 2022
    Messages : 3
    Points : 10
    Points
    10
    Par défaut Malloy, ça craint
    Que c'est nul le Malloy, on ne verra jamais ça nulle part...

    SQL c'est facile, efficace et puissant, aucun intérêt de vouloir inventer un truc aussi compliqué qu'inutile pour le remplacer.

  12. #12
    Membre émérite
    Inscrit en
    janvier 2006
    Messages
    684
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 684
    Points : 2 532
    Points
    2 532
    Par défaut Est-ce quel?
    Citation Envoyé par Bruno Voir le message
    Ce langage informatique est notamment très utilisé par les développeurs web pour communiquer avec les données d’un site web.
    A l'heure où les sites web, justement, sont bien plus prompts à passer à NoSQL que le commun des entreprises, je trouve quand même ça bien réducteur de présenter SQL sous cet angle...

    Citation Envoyé par Bruno Voir le message
    la formation des programmeurs est le coût dominant pour un langage de programmation.
    En tant que programmeur, pendant les cours à la fac, on m'a d'abord expliqué l'algèbre relationnelle et seulement ensuite le langage SQL. Et justement, le problème soulevé ici est que l'ordre des clauses dans SQL ne respecte pas l'algèbre relationnelle. Donc pas la manière dont un programmeur concevra une requête

    Citation Envoyé par AoCannaille Voir le message
    Le SQL essaye de se rapprocher d'un langage naturel,
    Comme le Cobol, qui date de la même époque, et justement je ne suis pas certain que ce soit une si bonne idée. A l'époque où les ordinateurs étaient peu répandus et peu performants, ça avait du sens de vouloir que l'ouvrier un peu qualifié puisse faire lui-même une requête dans le langage de la base pour vérifier le résultat de son travail. Aujourd'hui on encapsule tout dans des applis web, donc il est naturel que seuls des programmeurs maîtrisent le langage de la base (surtout qu'on ne veut peut-être pas donner accès à tous les champs) et de ne laisser aux utilisateurs un accès qu'à ce qui est pertinent pour eux.

    Citation Envoyé par AoCannaille Voir le message
    et je trouve que l'ordre que tu propose ne s'applique ni au français, ni à l'anglais.
    ça ressemblerait plutôt au japonais en effet (même si dans ce cas les particules seraient plutôt après ce qu'elles qualifient): du plus général au plus particulier. Je dis juste ça au cas où tu penserais que l'ordre proposé ne correspond pas à un langage naturel...

    Citation Envoyé par AoCannaille Voir le message
    En SQL, sauf erreur de ma part, la syntaxe "select nom_table.nom_champs from nom_table" est valide.
    Sauf que dans le from tu peux avoir des alias (from mytable m, voire même from (select ...) myAlias), auquel cas on est bien obligé d'avoir le from avant pour avoir l'auto-complétion.

  13. #13
    Expert confirmé
    Homme Profil pro
    Inscrit en
    septembre 2006
    Messages
    2 829
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : septembre 2006
    Messages : 2 829
    Points : 4 138
    Points
    4 138
    Par défaut
    https://www.iso.org/standard/76583.html

    l'état de la prochaine version du standard...

  14. #14
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Retraité
    Inscrit en
    mai 2002
    Messages
    8 981
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2002
    Messages : 8 981
    Points : 30 130
    Points
    30 130
    Par défaut
    Citation Envoyé par x_x_x_o Voir le message
    Commencer par le from a l'avantage que dans les lignes suivantes il peut proposer l'autocomplétion.
    Quand tu commences par select on ne sait pas d'où vont provenir les données donc pas possible de proposer la liste des colonnes possible afin de faciliter l'écriture de la requête.
    Pour bénéficier de l'auto-complétion, il suffit de commencer sa requête par SELECT *, décrire la clause FROM puis revenir détailler les colonnes du SELECT. En quoi serait-ce compliqué ?
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  15. #15
    Membre éclairé
    Homme Profil pro
    Formateur en informatique
    Inscrit en
    septembre 2012
    Messages
    415
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Formateur en informatique
    Secteur : Associations - ONG

    Informations forums :
    Inscription : septembre 2012
    Messages : 415
    Points : 736
    Points
    736
    Par défaut
    Citation Envoyé par sergio_is_back Voir le message
    A la maison j'utilise le même marteau depuis plus de 40 ans
    Malgré quelques clous plantés de travers force est de constaté qu'il convient toujours aussi bien

    Je devrais le remplacer par quoi ? une clé à molette, une banane en mousse ?
    Un marteau connecté. Mais il faudra apprendre à l'utiliser (notice fournie).

  16. #16
    Membre éclairé
    Homme Profil pro
    Formateur en informatique
    Inscrit en
    septembre 2012
    Messages
    415
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Formateur en informatique
    Secteur : Associations - ONG

    Informations forums :
    Inscription : septembre 2012
    Messages : 415
    Points : 736
    Points
    736
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Aujourd'hui on encapsule tout dans des applis web, donc il est naturel que seuls des programmeurs maîtrisent le langage de la base (surtout qu'on ne veut peut-être pas donner accès à tous les champs) et de ne laisser aux utilisateurs un accès qu'à ce qui est pertinent pour eux.
    Les applis web manipulent de l'information (aujourd'hui souvent via des api & microservices). Le SQL manipule de la donnée, ce qui est différent

  17. #17
    Membre confirmé

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

    Informations forums :
    Inscription : mai 2003
    Messages : 280
    Points : 639
    Points
    639
    Billets dans le blog
    1
    Par défaut
    Il y a des dizaines de langages dérivés du SQL qui lui apporte de la modularité, des variables, ... Du COBOL DB2 jusqu'à Linq... Et autant d'interprétateur (là où se situe la réelle complexité/les gains) donc ca me fait un peu peur quand les mecs disent être les premiers à innover.

  18. #18
    Membre expérimenté
    Homme Profil pro
    Développeur Oracle
    Inscrit en
    décembre 2019
    Messages
    983
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Oracle

    Informations forums :
    Inscription : décembre 2019
    Messages : 983
    Points : 1 636
    Points
    1 636
    Par défaut
    L'interêt du langage SQL est qu'il proche du langage humain.

    Ex:
    Je SELECTionne le PRIX et la QUANTITE DEPUIS la table de VENTES OU la DATE DE VENTE est la date du jour.
    Je SELECTionne les articles DEPUIS la table des ARTICLES pour lesquelles IL N'EXISTE PAS de vente dans la table de VENTES aujourd'hui.

    Pourquoi le rendre moins proche en utilisant un pseudo-langage qui au final produit l'objectif inverse, à mon humble avis.

  19. #19
    Membre émérite
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    813
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : août 2003
    Messages : 813
    Points : 2 264
    Points
    2 264
    Par défaut
    Citation Envoyé par vanagreg Voir le message
    L'interêt du langage SQL est qu'il proche du langage humain.

    Ex:
    Je SELECTionne le PRIX et la QUANTITE DEPUIS la table de VENTES OU la DATE DE VENTE est la date du jour.
    Je SELECTionne les articles DEPUIS la table des ARTICLES pour lesquelles IL N'EXISTE PAS de vente dans la table de VENTES aujourd'hui.

    Pourquoi le rendre moins proche en utilisant un pseudo-langage qui au final produit l'objectif inverse, à mon humble avis.
    Il me semble que dans mes cours de SQL, le professeur nous avait dit que le langage avait été conçu de façon à se rapprocher du langage parlé.

    Sinon, pour moi le SQL n'a pas spécialement besoin de remplacement. Je dirais qu'il faudrait gommer les éléments des différents SGBD (MySQL, Oracle, PostgreSQL) dans le but d'avoir la même syntaxe partout.
    Éventuellement avoir des modules normalisés serait intéressant (comme Postgis)

  20. #20
    Expert éminent sénior

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    2 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2016
    Messages : 2 690
    Points : 10 498
    Points
    10 498
    Billets dans le blog
    21
    Par défaut
    Le véritable reproche fait à SQL est fait par... des développeurs frustrés (dont je suis ) qui ne peuvent compter sur l'autocomplétion proposée par leur IDE lors de l'écriture des requêtes.

    Maintenant, SQL a quand même de sacrés avantages, dont celui d'être lisible, y compris par quelqu'un qui ne connait pas SQL (il ne comprendra pas forcément toutes les subtilités bien sûr, mais il pourra grosso modo comprendre d'où viennent les données, ce qui est affiché, etc..).

    Enfin, si SQL doit être remplacé "suite à l'absence de MAJ importantes depuis des décennies", il devrait en être de même pour de nombreux outils (tar, gz, cp, ...) et pleins de langages (C, Fortran, Ada pour n'en citer que quelques uns). Il est dommage de confondre obsolescence et maturité...
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

Discussions similaires

  1. [SQL][C#] Pas d'accès aux données d'une base SQL
    Par ridd21 dans le forum Windows Forms
    Réponses: 3
    Dernier message: 20/06/2006, 10h46
  2. Erreur : ce code n'est pas connu
    Par ruman dans le forum VBA Access
    Réponses: 17
    Dernier message: 13/02/2006, 11h37
  3. [SQL*Net] pas de listener : TNS-12547
    Par aline dans le forum Oracle
    Réponses: 2
    Dernier message: 30/05/2005, 11h05
  4. sql ne comprend pas mon where!et me demande des parametres
    Par marie10 dans le forum Langage SQL
    Réponses: 10
    Dernier message: 20/04/2004, 11h08
  5. probleme avec requete sql aime pas les strings
    Par lil_jam63 dans le forum Bases de données
    Réponses: 3
    Dernier message: 24/02/2004, 14h45

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