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 :

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


Sujet :

Langage SQL

  1. #21
    Membre chevronné
    Inscrit en
    janvier 2006
    Messages
    603
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 603
    Points : 2 065
    Points
    2 065
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Encore une fois il s'agit d'apprendre le SQL !.
    Bon, vu que tous les DBA SQL persistent à (faire semblant de) ne pas comprendre:
    ok ça va calmez vous oubliez le mot difficile et remplacez par : beaucoup trop verbeux eu égard au fait que ce type de requête est plutôt fréquent. ça va comme ça?
    Non? ok je précise encore

    Répéter trois fois "select * from R1", c'est un coup à faire des erreurs (encore ici on a de la chance que tous les select aient la même liste de colonnes...)
    N'importe quel langage de programmation a aujourd'hui un opérateur OU PARESSEUX (si quelqu'un a une meilleure traduction je suis preneur) qui correspond précisément à cette requête.
    Il m'aurait paru logique d'écrire quelque chose comme
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    select * from demo where src = ? or else src like ?
    ou, pour avoir plus de souplesse (je rajoute un champ juste pour montrer l'intérêt)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    (select *, 'exact' as type from demo where src = ?) or else (select *, 'fuzzy' as type from demo src like ?)
    Avant de hurler, oui je sais c'est pas du SQL, c'est juste ce que n'importe quel langage de programmation digne de ce nom aurait permis de faire.
    Ah oui mais SQL n'est pas un langage de programmation, c'est sûrement ça...

    Citation Envoyé par Waldar Voir le message
    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).
    Si tu fais toujours des recherches exactes, sans doute. Dans le monde de la traduction, en revanche, on fait beaucoup de recherches approchantes (objectif: permettre à un traducteur de s'inspirer de textes similaires traduits il y a longtemps) et là je préfère de loin que le traducteur voit des exemples datant de plusieurs mois (et qui ont donc été validés depuis longtemps) plutôt que de le voir quitter l'application parce qu'à chaque phrase traduite il perd dix secondes parce que le système attend que tous les nœuds aient confirmé le commit avant de rendre la main.
    En plus dans notre cas c'est d'avantage des INSERT et très peu d'UPDATE, donc la synchronisation à postériori (faite pendant la nuit de façon automatique) ne présente pas beaucoup de difficultés.
    Je ne prends pas ce cas pour une généralité, je dis juste que la contrainte de cohérence n'en est pas une dans certains cas.

    Et moi non plus je ne jette pas complètement SQL, je préfère juste varier les outils suivant le problème posé plutôt que de partir du principe que tout doit être fait à l'identique.

  2. #22
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 890
    Points : 49 635
    Points
    49 635
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Waldar Voir le message

    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.
    Note bien que SQL Server est revenu là dessus en proposant le mode Tabular…. Quand à la BI temps réel, donc sur des bases OLTP, ça se fait de plus en plus chez MS via le "In Memory" ou les index verticaux. Sur ces sujets MS est d'ailleurs plus pointu que son principal concurrent Oracle…

    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #23
    Membre expérimenté
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    septembre 2016
    Messages
    718
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2016
    Messages : 718
    Points : 1 372
    Points
    1 372
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Ah oui mais SQL n'est pas un langage de programmation, c'est sûrement ça...
    Tu connais beaucoup de langages qui passent par la création d'un plan d’exécution avant compilation puis exécution ?
    En dehors du SQL bien sûr.

    L'avantage du SQL c'est qu'il y a une norme derrière.
    Si l'idée proposée est lumineuse, elle n'aura aucun mal à être intégrée à la norme.
    Le savoir est une nourriture qui exige des efforts.

  4. #24
    Membre chevronné
    Inscrit en
    janvier 2006
    Messages
    603
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 603
    Points : 2 065
    Points
    2 065
    Par défaut
    Citation Envoyé par Michel.Priori Voir le message
    Tu connais beaucoup de langages qui passent par la création d'un plan d’exécution avant compilation puis exécution ?
    Pour moi, un plan d'exécution, c'est une forme de compilation (ou d'optimisation pendant la compilation, si tu préfères): ça consiste à convertir ta requête en quelque chose que la machine exécute plus facilement - ça produit le même résultat même si ça le fait en utilisant d'autres étapes que celles que le programmeur avait prévu. Compiler, ce n'est pas forcément traduire vers l'assembleur natif de ta machine. C'est un peu comme si ton serveur était une machine virtuelle, le EXPLAIN PLAN convertissant juste les expressions compilées en quelque chose de lisible par un humain.

    L'avantage du SQL c'est qu'il y a une norme derrière.
    L'avantage par rapport à quoi?
    NoSQL c'est peut-être encore vaste mais on voit quand même se dégager des tendances: les bases XML (et XML c'est une norme), les bases JSON (et JSON c'est une norme)... après c'est vrai qu'il n'y a pas encore de langage de requêtes normalisé pour XML ou JSON, mais si ce genre de bases tend à se généraliser, ça viendra.

  5. #25
    Membre expérimenté
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    septembre 2016
    Messages
    718
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2016
    Messages : 718
    Points : 1 372
    Points
    1 372
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Pour moi, un plan d'exécution, c'est une forme de compilation (ou d'optimisation pendant la compilation, si tu préfères)
    "Pigeons, cochons, ... tout ça c'est de la volaille"
    Le fait que l'algorithme de résolution soit choisi en fonction de sa qualification n'est pas de même nature que l'optimisation de l’exécution !
    Le savoir est une nourriture qui exige des efforts.

  6. #26
    Membre expérimenté
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    septembre 2016
    Messages
    718
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2016
    Messages : 718
    Points : 1 372
    Points
    1 372
    Par défaut
    Citation Envoyé par esperanto Voir le message
    L'avantage par rapport à quoi?
    [...]et JSON c'est une norme
    La norme n'est rien en soit. C'est le processus normatif qui est important. Le second amenant au premier.

    TCP/IP n'est pas parfait non plus.
    Comment se passent les évolutions ?
    Est-ce que c'est un frein ou un gage d'évolution pérenne ?

    Donc oui, être adossé à une norme c'est un avantage.
    Le savoir est une nourriture qui exige des efforts.

  7. #27
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 890
    Points : 49 635
    Points
    49 635
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par esperanto Voir le message
    ... les bases XML (et XML c'est une norme), les bases JSON (et JSON c'est une norme)...
    NON, NON et NON… tois fois non !

    Les SGBD XML ont existés au début des années et sont tous morts par darwinisme. Le dernier en date était Tamino d'AG Software… Compte tenu de la verbosité du stockage le volume des données stockées était le triple de celles des SGBDR et les performances catastrophique car il est extrément difficile d'indexer du XML….
    Quant au XML et au JSON, ce ne sont absolument pas des normes… mais des standards. Il y a une différence fondamentale :

    Les normes sont validés par des organismes coopératifs (des industriels qui se réunissent) et publiés de manière officielle (AFNOR en France, ANSI aux USA, et finalement ISO au niveau international).
    Le langage SQL est une norme ISO (9075) compte tenu de sa très vaste utilisation et de sa longévité, longévité et donc pérennité acquise, justement du fait du cadre normatif… Autres exemple : SGML (ISO 8879)

    Les standards sont décidés par une entreprise ou un organisme, sans concertation, et publié à titre personnel. Il peuvent être fermé (droits à payer, exemple en TV les standards PAL SECAM, NTSC) ou ouverts (donc gratuits comme HTML : https://html.spec.whatwg.org/multipage/, XML : https://www.w3.org/XML/ ou encore OGC http://www.opengeospatial.org/docs/is)

    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  8. #28
    Membre chevronné
    Inscrit en
    janvier 2006
    Messages
    603
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 603
    Points : 2 065
    Points
    2 065
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    il est extrément difficile d'indexer du XML….
    Ah bon? Pourtant il suffit de lire la doc
    (ben quoi? moi aussi je peux faire comme vous et prendre ce que vous dites au pied de la lettre pour conclure ce qui m'arrange...)

  9. #29
    Membre expert
    Inscrit en
    juin 2009
    Messages
    1 066
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 1 066
    Points : 3 300
    Points
    3 300
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Les normes sont validés par des organismes coopératifs (des industriels qui se réunissent) et publiés de manière officielle (AFNOR en France, ANSI aux USA, et finalement ISO au niveau international).
    Le langage SQL est une norme ISO (9075) compte tenu de sa très vaste utilisation et de sa longévité, longévité et donc pérennité acquise, justement du fait du cadre normatif… Autres exemple : SGML (ISO 8879)

    Les standards sont décidés par une entreprise ou un organisme, sans concertation, et publié à titre personnel. Il peuvent être fermé (droits à payer, exemple en TV les standards PAL SECAM, NTSC) ou ouverts (donc gratuits comme HTML : https://html.spec.whatwg.org/multipage/, XML : https://www.w3.org/XML/ ou encore OGC http://www.opengeospatial.org/docs/is)

    A +
    Merci pour ce rappel, A chaque fois que je corrige quelqu'un en parlant de la différence entre Norme et Standard je sais faire exactement ces deux définitions, mais je les inverses régulièrement, du coup après une longue tirade ça fini toujours par "Ou l'inverse, peu importe, en tout cas c'est différent!" ce qui décrédibilise quelque peut la pertinence des propos

  10. #30
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 215
    Points : 5 157
    Points
    5 157
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Quant au XML et au JSON, ce ne sont absolument pas des normes… mais des standards. Il y a une différence fondamentale :

    Les normes sont validés par des organismes coopératifs (des industriels qui se réunissent) et publiés de manière officielle (AFNOR en France, ANSI aux USA, et finalement ISO au niveau international).
    Le langage SQL est une norme ISO (9075) compte tenu de sa très vaste utilisation et de sa longévité, longévité et donc pérennité acquise, justement du fait du cadre normatif… Autres exemple : SGML (ISO 8879)

    Les standards sont décidés par une entreprise ou un organisme, sans concertation, et publié à titre personnel. Il peuvent être fermé (droits à payer, exemple en TV les standards PAL SECAM, NTSC) ou ouverts (donc gratuits comme HTML : https://html.spec.whatwg.org/multipage/, XML : https://www.w3.org/XML/ ou encore OGC http://www.opengeospatial.org/docs/is)
    Aurais-tu une source sur cette différence de sémantique ?
    Je viens de regarder standard et norme dans plusieurs dictionnaires français, dont le TLF, et je n'ai pas vu tes définitions.
    Idem pour standard et norm dans un dictionnaire anglais (Oxford English Dictionary).

  11. #31
    Membre expérimenté
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    septembre 2016
    Messages
    718
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2016
    Messages : 718
    Points : 1 372
    Points
    1 372
    Par défaut
    Un "standard" peut être de fait.
    Une "norme" non.
    Le savoir est une nourriture qui exige des efforts.

  12. #32
    Membre chevronné
    Inscrit en
    janvier 2006
    Messages
    603
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 603
    Points : 2 065
    Points
    2 065
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    mais des standards. Il y a une différence fondamentale :
    Et cette différence entraine quoi? Franchement, en dehors du monde universitaire, je me vois mal dire à mon patron "je ne vais pas implémenter JSON parce que c'est un standard et pas une norme". Surtout qu'il n'existe pas de norme remplissant le même objectif: qu'est-ce qu'on peut y faire si l'ISO ne s'est pas intéressé au problème des formats de sérialisation?
    Et puis franchement, je préfère encore les "recommandations" du W3C à l'insipide "norme" OpenXML (tiens, ça les a pas gênés que XML soit pas une norme du coup...) qui n'a été validée que parce que son promoteur donnait un peu plus d'argent à l'ISO que les autres...

    Tiens au passage, Unicode c'est un standard ou une norme d'après ta définition? Attention il y a un piège...

  13. #33
    Membre expérimenté
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    septembre 2016
    Messages
    718
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2016
    Messages : 718
    Points : 1 372
    Points
    1 372
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Franchement, en dehors du monde universitaire, je me vois mal dire à mon patron "je ne vais pas implémenter JSON parce que c'est un standard et pas une norme".
    Comme disait ma grand-mère : "s'il avait fallut les attendre pour inventer le fil à couper le beurre, on le couperait encore à la hache."
    Heureusement que l'invention et le progrès n'est pas "normatif" !

    Pour autant, et c'est l'objet du post, attaquer de front un standard existant pour dire qu'il mérite une mise à jour majeure est soit l’œuvre d'un génie (et faut pas imaginer qu'il n'en n'existe pas) soit un élan d'humeur d'un trublion.
    Ça se discute. Ça s'arbitre.

    Quand on voit que l'adoption de l'écriture des JOIN, norme 1992, n'est toujours pas adopté par certains programmeurs Oracle (de moins de 20 ans, sinon c'est pas drôle), je me dis que si c'est pour faire pareil en mieux, il y a de fortes chances pour que ça reste lettre morte pour un bout de temps.

    Citation Envoyé par esperanto Voir le message
    Et cette différence entraine quoi?
    Où en est la bataille entre le PAL et le SECAM ?
    Où en est la norme IEEE 802.5. ?

    Je répète, l'avantage d'une norme, est que les challenges sont protocolairement prévus.
    C'est ce protocole d'intégration de la nouveauté qui est un avantage.
    En soit, la norme n'est pas un but et ne confère absolument rien si l'adoption n'est pas au rendez-vous.

    Les normes "actives", c'est à dire, pour lesquelles il y a des participants et des enjeux (je pense notamment au réseau téléphonique 2g, 3g, 4g, 5g ...) les évolutions ne manquent pas.

    La question qui me vient est : pourquoi cette proposition n'est pas une proposition auprès de l'agence ANSI ?
    Le savoir est une nourriture qui exige des efforts.

  14. #34
    Membre éclairé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    décembre 2008
    Messages
    86
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2008
    Messages : 86
    Points : 746
    Points
    746
    Par défaut
    si il n'aime pas SQL, il n'a qu'à utiliser un ORM...

  15. #35
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 890
    Points : 49 635
    Points
    49 635
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par esperanto Voir le message
    Et cette différence entraine quoi? Franchement, en dehors du monde universitaire, je me vois mal dire à mon patron "je ne vais pas implémenter JSON parce que c'est un standard et pas une norme". Surtout qu'il n'existe pas de norme remplissant le même objectif: qu'est-ce qu'on peut y faire si l'ISO ne s'est pas intéressé au problème des formats de sérialisation?
    Et puis franchement, je préfère encore les "recommandations" du W3C à l'insipide "norme" OpenXML (tiens, ça les a pas gênés que XML soit pas une norme du coup...) qui n'a été validée que parce que son promoteur donnait un peu plus d'argent à l'ISO que les autres...

    Tiens au passage, Unicode c'est un standard ou une norme d'après ta définition? Attention il y a un piège...
    fait un petit effort intellectuel. Relit ce que j'ai dit !

    Quand aux questions piège à con, j'ai d'autres chats à fouetter !

    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  16. #36
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 666
    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 : 7 666
    Points : 26 240
    Points
    26 240
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Michel.Priori Voir le message
    Quand on voit que l'adoption de l'écriture des JOIN, norme 1992, n'est toujours pas adopté par certains programmeurs Oracle (de moins de 20 ans, sinon c'est pas drôle), je me dis que si c'est pour faire pareil en mieux, il y a de fortes chances pour que ça reste lettre morte pour un bout de temps.
    Pas seulement Oracle, loin s'en faut

    Et pire : nombreux sont les enseignants à encore ignorer l'usage de l'opérateur JOIN et qui donnent des cours en codant les jointures dans le WHERE

  17. #37
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    janvier 2013
    Messages
    368
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : janvier 2013
    Messages : 368
    Points : 1 254
    Points
    1 254
    Par défaut
    Les optimiseurs rendent la nuance syntaxique inopérante depuis un moment, non?
    Sinon, pour l'adoption du SQL moderne, il reste encore des progrès à faire c'est sûr.

  18. #38
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 666
    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 : 7 666
    Points : 26 240
    Points
    26 240
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par MaximeCh Voir le message
    Les optimiseurs rendent la nuance syntaxique inopérante depuis un moment, non?
    Depuis toujours, mais la lecture des requêtes en est facilitée, surtout pour Oracle qui avait proposé une syntaxe particulière qui peut déconcerter les développeurs ayant une culture non Oracle

  19. #39
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    janvier 2013
    Messages
    368
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : janvier 2013
    Messages : 368
    Points : 1 254
    Points
    1 254
    Par défaut
    D'ailleurs quelque chose qui m'embête depuis un moment : est-t-il possible de garder la syntaxe join uniquement, et ne pas utiliser where, quand il y a un cycle dans le chemin de jointure?

    Nvm, TIL, c'est possible, au moins avec postgresql.
    Il suffit de fermer le cycle dans le dernier "join on and" une fois que toutes les tables impliquées ont été déclarées dans leurs clauses join respectives.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    select * 
    from tabA 
    join tabB on tabA.id=tabB.id
    join tabC on tabB.id=tabC.id and tabC.id=tabA.id
    ;

  20. #40
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    8 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Val de Marne (Île de France)

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

    Informations forums :
    Inscription : septembre 2008
    Messages : 8 188
    Points : 17 070
    Points
    17 070
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Depuis toujours, mais la lecture des requêtes en est facilitée, surtout pour Oracle qui avait proposé une syntaxe particulière qui peut déconcerter les développeurs ayant une culture non Oracle
    Oracle avait le (+) sur les colonnes, mais Sybase et SQL-Server avaient le =* au niveau de l'opérateur.
    On ne peut pas reprocher aux éditeurs de trouver des solutions aux problèmes réels, et c'est en ça que la norme SQL est importante, elle permet de converger vers une syntaxe de plus en plus ressemblante.
    Mais ça n'empêchera pas les éditeurs de déployer de nouvelles fonctionnalités avec de nouvelles syntaxes, ce qui est in fine une bonne chose.

Discussions similaires

  1. [MySQL] Faire une requete sql qui affiche les ip actifs
    Par Gghizlane dans le forum PHP & Base de données
    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