Publicité
+ Répondre à la discussion
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 23
  1. #1
    Membre régulier
    Homme Profil pro Patrice Delorme
    Inscrit en
    mai 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrice Delorme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : mai 2007
    Messages : 187
    Points : 71
    Points
    71

    Par défaut Fonctionnement ORDER BY dans un GROUP BY

    Bonjour,

    J'ai la requette suivante qui me retourne les dernière visite (par date) lié à un couple intervention/equipement :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    SELECT 
                           LAST(x.intervention_id)    AS intervention_id, 
                           LAST(x.equip_vess_id)      AS equip_vess_id, 
                           LAST(x.visit_id)           AS visit_id, 
                           LAST(x.finish_dttm)        AS finish_dttm,
                        FROM (SELECT i1.intervention_id, v.visit_id, v.equip_vess_id, v.finish_dttm, v.finish_meter_value
                                FROM interventions i1, interventions i2, visits v
                               WHERE i1.intervention_log_group_id = i2.intervention_log_group_id AND i2.intervention_id = v.intervention_id
                               ORDER BY v.finish_dttm) x
                       GROUP BY x.equip_vess_id
    Cette requette ne retourne pas la derniere ligne en date du groupe, mais uen autre.
    en creusant nous avons finalement trouvé qu'il fallais qye l'order by soit sur
    Code :
     i1.intervention_id,v.equip_vess_id,v.finish_dttm
    ce qui ne parait pas logique.
    En effet il semble que l'order by regroupe le résultat de la sous requette sans tenir compte du tri.
    Mon problème est résolu, mais j'aimerias bien avoir comprendre ou se trouve l'erreur (dans ma logique ou dans le moteur postgres)

    Merci,

    P

  2. #2
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 032
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 032
    Points : 4 599
    Points
    4 599

    Par défaut

    Bonjour,

    Quelle version de postgresql utilisez vous ?

    LAST ne semble pas exister en v9.0+

  3. #3
    Membre régulier
    Homme Profil pro Patrice Delorme
    Inscrit en
    mai 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrice Delorme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : mai 2007
    Messages : 187
    Points : 71
    Points
    71

    Par défaut

    effectivement, LAST() est une fonction maison (super pratique)... je suis sur postgres 8.3

    La fonction last :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
     
    CREATE OR REPLACE FUNCTION last_agg(anyelement, anyelement)
      RETURNS anyelement AS
    $BODY$
            SELECT $2;
    $BODY$
      LANGUAGE sql STABLE
      COST 100;
    ALTER FUNCTION last_agg(anyelement, anyelement) OWNER TO postgres;
     
    CREATE AGGREGATE "last"(anyelement) (
      SFUNC=last_agg,
      STYPE=anyelement
    );
    ALTER AGGREGATE "last"(anyelement) OWNER TO postgres;
    P.

  4. #4
    Membre régulier
    Homme Profil pro Patrice Delorme
    Inscrit en
    mai 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrice Delorme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : mai 2007
    Messages : 187
    Points : 71
    Points
    71

    Par défaut

    en cadeau la fonction FIRST :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
     
    CREATE OR REPLACE FUNCTION first_agg(anyelement, anyelement)
      RETURNS anyelement AS
    $BODY$
            SELECT CASE WHEN $1 IS NULL THEN $2 ELSE $1 END;
    $BODY$
      LANGUAGE sql STABLE
      COST 100;
    ALTER FUNCTION first_agg(anyelement, anyelement) OWNER TO postgres;
     
    CREATE AGGREGATE "first"(anyelement) (
      SFUNC=first_agg,
      STYPE=anyelement
    );
    ALTER AGGREGATE "first"(anyelement) OWNER TO postgres;
    P.

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    Votre erreur vient du fait que la clause ORDER BY est normalement interdite dans les sous requêtes. Même si vous la mettez elle n'a en général aucun effet.
    En effet, la clause ORDER BY n'est, par nature, par relationnelle. Elle ne sert qu'a présenter un résultat (et non pas une table dérivée, c'est à dire une table créée à la volée dans une sous requête) et c'est que que l'on appelle une clause COSMÉTIQUE. À me lire : http://sqlpro.developpez.com/cours/sqlaz/erreurs/#L9

    Pour réaliser des opérations ordonnées, il existe toute une classe de fonction appelées fonction de fenêtrage, comme RANK(), ROW_NUMBER(), LEAD(), LAG().
    Apprenez le langage SQL. Notamment : http://sqlpro.developpez.com/article...clause-window/

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  6. #6
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 032
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 032
    Points : 4 599
    Points
    4 599

    Par défaut

    Donc vous utilisez des fonctions "maisons" dont vous ne comprenez pas le méchanisme ? :p

    un test tout simple qui vous permettra de comprendre son fonctionnement :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
     
    WITH tmp (id, val) AS (
    SELECT 1, 3 union ALL 
    SELECT 1, 2 union ALL
    SELECT 2, 4)
     
    SELECT *
    FROM tmp
    Resultat :
    Code :
    1
    2
    3
    4
    5
    6
     
    id         val
    -------------------
    1          3
    1          2
    2          4

    Avec votre fonction :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    WITH tmp (id, val) AS (
    SELECT 1, 3 union ALL 
    SELECT 1, 2 union ALL
    SELECT 2, 4)
     
    SELECT last(val)
    FROM tmp
    GROUP BY id
    Résultat :
    Code :
    1
    2
    3
    4
    5
     
    id            val
    ------------------
    1             2
    2             4

  7. #7
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 032
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 032
    Points : 4 599
    Points
    4 599

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Votre erreur vient du fait que la clause ORDER BY est normalement interdite dans les sous requêtes. Même si vous la mettez elle n'a en général aucun effet.
    A +
    Bonjour,


    Dans le cas de PostGresql ca me semble un peu différent. (je ne remet en cause le fait que cela soit interdit ou non au vu de la norme).

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
     
    WITH tmp(id) AS (
    SELECT 2 union ALL
    SELECT 5 union ALL
    SELECT 1)
     
    SELECT min(id)
    FROM (SELECT id FROM tmp ORDER BY id) AS a
    Explain :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
    "Aggregate  (cost=0.19..0.20 rows=1 width=4)"
    "  CTE tmp"
    "    ->  Result  (cost=0.00..0.06 rows=3 width=4)"
    "          ->  Append  (cost=0.00..0.06 rows=3 width=4)"
    "                ->  Result  (cost=0.00..0.01 rows=1 width=0)"
    "                ->  Result  (cost=0.00..0.01 rows=1 width=0)"
    "                ->  Result  (cost=0.00..0.01 rows=1 width=0)"
    "  ->  Sort  (cost=0.08..0.09 rows=3 width=4)"
    "        Sort Key: tmp.id"
    "        ->  CTE Scan on tmp  (cost=0.00..0.06 rows=3 width=4)"
    On voit bien ici que PG réalise le sort de la sous-requête avant de le passer dans la fonction d’agrégation

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    Citation Envoyé par punkoff Voir le message
    Bonjour,


    Dans le cas de PostGresql ca me semble un peu différent. (je ne remet en cause le fait que cela soit interdit ou non au vu de la norme).
    NON !!!!

    Votre position est parfaitement idiote, car il n'y a aucune garantie de reproduction du résultat, le SGBDR étant libre de lire les données dans l'ordre qu'il souhaite et non dans celle que vous lui indiquez (gestion ensembliste).
    Malheureusement mettre cela en évidence, nécessite des jeux de données importants (dépassant le volume du cache) et diffère suivant l'indexation.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  9. #9
    Expert Confirmé
    Profil pro
    Inscrit en
    octobre 2008
    Messages
    1 822
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : octobre 2008
    Messages : 1 822
    Points : 2 517
    Points
    2 517

    Par défaut

    Citation Envoyé par pdelorme Voir le message
    Mon problème est résolu, mais j'aimerias bien avoir comprendre ou se trouve l'erreur (dans ma logique ou dans le moteur postgres)
    Le problème est que manifestement la requête est fausse, c.a.d qu'elle ne donnera pas les résultats voulus dans 100% des cas.
    Ca ne devrait pas être trop compliqué de la réécrire dans une version juste.

    Sachant qu'en 8.3 il n'y pas de fonction de fenêtrage, il faut procéder en extrayant d'abord la date max avec GROUP BY qui va bien et ensuite en joignant avec le reste pour récupérer les valeurs des autres colonnes associées à cette date.

  10. #10
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 032
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 032
    Points : 4 599
    Points
    4 599

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    NON !!!!

    Votre position est parfaitement idiote, car il n'y a aucune garantie de reproduction du résultat, le SGBDR étant libre de lire les données dans l'ordre qu'il souhaite et non dans celle que vous lui indiquez (gestion ensembliste).
    Malheureusement mettre cela en évidence, nécessite des jeux de données importants (dépassant le volume du cache) et diffère suivant l'indexation.

    A +
    Bonjour,


    Nous parlons de postgresql ici.

    Je suis bien conscient de votre argumentation mais si vous faites des recherches ça ne semble pas si blanc / noir au niveau de se fonctionnement :

    http://postgresql.1045698.n5.nabble....td5527695.html

    En particulier les derniers message de la discussion.

    Si j’interprète bien ces messages (en particulier ceux de Tom Lane) :
    - La clause order by n'est pas légal dans une sous requete (sans utilisation d'un top / offset ?)
    - Si un utilisateur en à mis une c'est pour une raison bien précise.
    - A partir de ce moment là l'order by est honnoré car l'utilisateur l'a mit


    edit : non valide

    nb: ce message n'est pas fait pour encourager notre posteur à continuer d'utiliser sa méthode mais de mieux comprendre certaine spécificité de l'optimiseur postgres

  11. #11
    Membre régulier
    Homme Profil pro Patrice Delorme
    Inscrit en
    mai 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrice Delorme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : mai 2007
    Messages : 187
    Points : 71
    Points
    71

    Par défaut

    Citation Envoyé par punkoff Voir le message

    Avec votre fonction :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    WITH tmp (id, val) AS (
    SELECT 1, 3 union ALL 
    SELECT 1, 2 union ALL
    SELECT 2, 4)
     
    SELECT last(val)
    FROM tmp
    GROUP BY id
    Résultat :
    Code :
    1
    2
    3
    4
    5
     
    id            val
    ------------------
    1             2
    2             4
    d'ou la nécessité du ORDER BY val dans l'innée sélection qui présente les données dans le bon ordre au GROUP BY et retourne le résultats attendu.

  12. #12
    Membre régulier
    Homme Profil pro Patrice Delorme
    Inscrit en
    mai 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrice Delorme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : mai 2007
    Messages : 187
    Points : 71
    Points
    71

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    NON !!!!

    Votre position est parfaitement idiote, car il n'y a aucune garantie de reproduction du résultat, le SGBDR étant libre de lire les données dans l'ordre qu'il souhaite et non dans celle que vous lui indiquez (gestion ensembliste).
    Malheureusement mettre cela en évidence, nécessite des jeux de données importants (dépassant le volume du cache) et diffère suivant l'indexation.

    A +
    Le problème que vous citez à effectivement été constaté (c'est même l'origine du bug)
    Selon la machine, notre requête initial ne retourne pas les mêmes résultats bien que les version postgres et Linux soient identiques... Peut être que la taille des cache diffère, à vérifier. Cependant, l'ajout d'un ORDER BY plus complet à permis de corriger le résultat... Il est clair que l'optimiseur postgres y est pour quelque chose...

  13. #13
    Membre régulier
    Homme Profil pro Patrice Delorme
    Inscrit en
    mai 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrice Delorme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : mai 2007
    Messages : 187
    Points : 71
    Points
    71

    Par défaut

    Citation Envoyé par estofilo Voir le message
    Le problème est que manifestement la requête est fausse, c.a.d qu'elle ne donnera pas les résultats voulus dans 100% des cas.
    Ca ne devrait pas être trop compliqué de la réécrire dans une version juste.

    Sachant qu'en 8.3 il n'y pas de fonction de fenêtrage, il faut procéder en extrayant d'abord la date max avec GROUP BY qui va bien et ensuite en joignant avec le reste pour récupérer les valeurs des autres colonnes associées à cette date.
    Le problème de cette approche est qu'elle me parait très consommatrice car plus complexe... Il me semble plus optimal (et élégant) de faire un tri puis un LAST (pour peu que cela fonctionne) que de faire un group by puis une jointure sur une date ce qui nécessite de faire 2 inner selects qui peuvent être relativement complexe...

  14. #14
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 032
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 032
    Points : 4 599
    Points
    4 599

    Par défaut

    Citation Envoyé par pdelorme Voir le message
    Le problème que vous citez à effectivement été constaté (c'est même l'origine du bug)
    Selon la machine, notre requête initial ne retourne pas les mêmes résultats bien que les version postgres et Linux soient identiques... Peut être que la taille des cache diffère, à vérifier. Cependant, l'ajout d'un ORDER BY plus complet à permis de corriger le résultat... Il est clair que l'optimiseur postgres y est pour quelque chose...
    Bah dans ce cas, vous ne pouvez pas garantir que ceci ne se reproduise pas donc cette solution est a jeter.

  15. #15
    Membre régulier
    Homme Profil pro Patrice Delorme
    Inscrit en
    mai 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrice Delorme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : mai 2007
    Messages : 187
    Points : 71
    Points
    71

    Par défaut

    Citation Envoyé par punkoff Voir le message
    Bah dans ce cas, vous ne pouvez pas garantir que ceci ne se reproduise pas donc cette solution est a jeter.
    Le ORDER BY plus complet à effectivement résolu mon problème, l'ORDER BY n'est donc pas qu'une fonction uniquement "cosmétique" et semble réellement pouvoir être utilisé comme je l'utilise (avec LAST() dans une inner query)...

    Mise à part une présomption de culpabilité, j'ai du mal à comprendre ce qui "concrètement" en interdit l'usage.

  16. #16
    Expert Confirmé
    Profil pro
    Inscrit en
    octobre 2008
    Messages
    1 822
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : octobre 2008
    Messages : 1 822
    Points : 2 517
    Points
    2 517

    Par défaut

    Citation Envoyé par pdelorme Voir le message
    Le ORDER BY plus complet à effectivement résolu mon problème, l'ORDER BY n'est donc pas qu'une fonction uniquement "cosmétique" et semble réellement pouvoir être utilisé comme je l'utilise (avec LAST() dans une inner query)...

    Mise à part une présomption de culpabilité, j'ai du mal à comprendre ce qui "concrètement" en interdit l'usage.
    C'est vraiment simple: le GROUP BY qui est fait sur la base des résultats de la sous-requête n'a pas à conserver le tri de la sous-requête, il est libre de réordonner les lignes comme il l'entend.

    L'ironie de cette discussion est que tu as toi-même constaté le problème dès le 1er message:
    En effet il semble que l'order by regroupe le résultat de la sous requette sans tenir compte du tri.
    mais que malgré tout, tu n'as pas l'air de vouloir y croire, alors que tu as la preuve sous les yeux.

  17. #17
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    Mais rien n'empêche les gens de se suicider !

    Actuellement vous ne voyez pas les effets de bord, car votre jeu de données est biaisé et comme vous pensez que vous avez raison, vous allez continuer stupidement à mettre en œuvre cela jusqu'au jour ou vos utilisateurs découvrirons sans doute trop tard les bogues que vous avez sciemment introduit en toute connaissance de cause dans le logiciel.

    Errare humanum est, perseverare diabolicum !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  18. #18
    Membre régulier
    Homme Profil pro Patrice Delorme
    Inscrit en
    mai 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrice Delorme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : mai 2007
    Messages : 187
    Points : 71
    Points
    71

    Par défaut

    Citation Envoyé par estofilo Voir le message
    mais que malgré tout, tu n'as pas l'air de vouloir y croire, alors que tu as la preuve sous les yeux.
    Il n'y a donc pas de place pour des fonctions d’agrégation LAST et FIRST et la seule solution est donc de faire un group by et une jointure sur la date max comme suggéré par estofilo ?

    J'ai effectivement du mal à croire que postgres n'ait pas la gentillesse de conserver mes Order by.

    Merci en tous cas pour ces explications qui m’ont remis dans le droit chemin!

    Amen !

  19. #19
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    Il serait peut être temps de comprendre ce qu'est un SGBD Relationnel !

    La théorie de l'Algèbre Relationnelle a été bâtie sur la théorie des ensembles qui ne possède aucune relation d'ordre de manière naturelle.

    La clause ORDER BY de SQL ne fait d'ailleurs pas partie de l'algèbre relationnelle.
    C'est pourquoi les SGBDR l'ignorent en général, ou bien signalent l'erreur, lorsqu'elle figure à l'intérieur des requêtes.
    En fait il s'agit d'une clause COSMÉTIQUE c'est à dire appliqué au rendu du résultat et c'est pourquoi elle ne doit figurer qu'une seule fois et à la toute fin de la requête.
    On a jugé plus pratique de rajouter cette clause au langage, parce qu'il est généralement moins couteux de demander au SGBDR de trier les données que de le faire sur le poste client. En effet, au niveau physique, il est parfois possible d'éviter le coût du traitement du tri par le simple fait de l'existence d'un index adéquat, puisqu'un index est généralement une forme de tri...

    Si vous regardez comment est conçu l'intérieur d'un SGBDR, vous remarquerez que la partie qui assure le tri n'est pas du tout située dans le moteur relationnel. En effet les requêtes sont de l'algèbre relationnelle, donc relève du moteur relationnel, c'est à dire de la partie LOGIQUE du SGBDR. En revanche le tri est une opération physique (le résultat d'une requête est le même que les données soient triées ou non) et relève donc du moteur de stockage !

    La partie logique (requêtes relationnelle) est assurée par le moteur relationnel, tandis que la partie physique est assurée par le moteur de stockage. Et c'est bien le moteur de stockage qui doit effectuer la lecture de l'index ou s'il n'y a pas d'index adéquat, effectuer l'opération physique des tri des lignes résultant de la requête relationnelle.

    Pour vous en convaincre, voici l'architecture interne de MS SQL Server...
    http://www.developpez.net/forums/att...1&d=1351259693

    Tous les SGBD relationnel sont bâtis sur les mêmes principes de séparation :
    Physique : stockage, indexation, lectures, écritures, verrouillage, gestion des transactions, chargement de données via des fichiers externe, sauvegarde, restauration...
    Logique : analyse grammaticale, vérification des privilèges, transformation diverses (XML, Full-Text, SIG...), algébrisation, optimisation, exécution...

    A +
    Images attachées Images attachées
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  20. #20
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    Citation Envoyé par pdelorme Voir le message
    Il n'y a donc pas de place pour des fonctions d’agrégation LAST et FIRST et la seule solution est donc de faire un group by et une jointure sur la date max comme suggéré par estofilo ?

    J'ai effectivement du mal à croire que postgres n'ait pas la gentillesse de conserver mes Order by.

    Merci en tous cas pour ces explications qui m’ont remis dans le droit chemin!

    Amen !
    Vous pouvez quand même utiliser les fonctions de fenêtrage LEAD et LAG. Elles sont implémentées dans PG depuis la version 9.

    À me lire : http://sqlpro.developpez.com/article...clause-window/

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •