Forums PostgreSQL.fr

bonjour

ce serait effectivement uine solution je pense, en fait comme je le disait precedement on utilise un framework ecri en interne pour générer nos requete de grille et pour le moment il repond à 99% des cas (le 1% etant mon cas à moi qui peut etre resolu en 2 requetes), du coup il faudrait soit faire une evolution du framework pour y inclure la gestion de la clause with soit passer en 2 requetes et le moins couteux et le plus rapide pour le moment est la 2eme solution, si j'ai du temps je ferais evoluer le framework effectivement en attendant "peut etre un jour" un  group by ou distinct dans les fonctions window .

merci beaucoup

presque mais du coup le count(distinct codification) from parution ne tient pas compte des conditions de la requete principal, si je rajotue des jointures

SELECT p.libelle, p.codification, p.numero, (SELECT count(DISTINCT codification) FROM parution) FROM parution p
join majointure1 A
join majointure2 B
join majointure3 C
where
A.datesuppression is null
and B.stock > 0
and C.libelle ilike 'toto';

il va falloir que je rajoute dans la sous requete les memes conditions
mais petit a petit tu arrive exactement a rejoindre mon probleme car ta prochaine idée sera surement de faire comme j'ai fait au debut avec directement :

SELECT p.libelle, p.codification, p.numero,  count(DISTINCT codification)  FROM parution p ....

mais vu qu il y a un limit afin de gérer la pagination et ne pas retourner au client 2000 lignes alors qu'on en veut uniquement 10, j'ai ajouté le mot clé over() pour ne pas s'areter au limit mais dès que je met le mot clé over(), je n'ai plus le droit d'utiliser distinct ou group by, comme je le disais je pense qu il me faudrait :

count(distinct codification) over() ou alors peut etre un count(codification) over(group by codification)  mais je ne crois pas que ce soit possible

ha peut etre qu'en rajoutant un over() dans la sous requete ca va peut etre fonctionner  :

SELECT p.libelle, p.codification, p.numero, s.count FROM parution p INNER JOIN (SELECT codification, count(*) over() FROM parution GROUP BY codification) s ON (p.codification = s.codification);

merci pour votre réponse,

le partition by me retourne toujours 1, j'avai deja essayé effectivement cette solution mais si j'ai bien compris le partition by va me retourner ce genre de chose:

titre         codification     numero   paritionBy
TOTO    3456                 1            2
TOTO    3456                 2            2
TITI        1234                 4            3
TITI        1234                 5            3
TITI        1234                 6            3
TATA      11111                1             1

mais moi j'aimerais avoir :

TOTO    3456                 1     3
TOTO    3456                 2     3
TITI        1234                 4     3
TITI        1234                 5     3
TITI        1234                 6     3
TATA      11111                1      3

car a l'affichage de mon resultat sur la page j'ai uniquement besoin d'avoir le nombre de titre unique donc dans mon cas j'ai bien 3456, 1234 et 11111 donc 3 titres et dans le tableau qui est affiché en dessous je dois afficher les 6 lignes car elle dispose d'un numero différent, il ne s'agit pas des memes parutions.

on peut tres bien avoir un tele Z numero 1 et un tele Z numero 2 donc je dois afficher les 2 lignes dans ma liste car je peut tres bien modifier soi l'un soi l'autre mais au niveau stat je doit afficher que je dispose d' un seul et unique titre.

je sais que je retourne sur chaque ligne une information identique mais je prefere cela plutot que de rejouer la requete une autre fois derriere sachant que postgres a deja tout le resultat en memoire donc autant qu il fasse le calcul directement.

mon souci c'est de ne pas avoir de count(distinct codification) over() ou alors peut etre un count(codification) over(group by codification) plutot que partition by je pense.

c'est d'ailleurs suite à une formation Dalibo ou l'ou nous a dis que les cast était très couteux ce qui parrait logique finalement que je me pose la question

je pense que la fonction qui est appelé est :

 \df texteq
                           List of functions
   Schema   |  Name  | Result data type | Argument data types |  Type  
------------+--------+------------------+---------------------+--------
 pg_catalog | texteq | boolean          | text, text          | normal

finalement la questions sur la difference entre distinct et group by resoud une partie de mon problème car l'un des deux influ sur les fonctions d'agregat, d'ou mon count(*) over qui me retourne 36 au lieu de 15

bon je vais voir comment corriger la jointure qui me retourne mes doublons, ce sera plus sage

merci pour l'aide quand meme

il ne s'agit malheureusement pas d'une grille mémoire, qui l'était d'ailleurs avant et pour laquelle le probleme que je rencontre aujourd hui n'étais pas. et aujourd hui cette grille devient persistente à chaque modification pour ne rien perdre car il s'agit d'une table longue à construire et si pour une raison X ou Y l'appli venait à s'arretter ou le navigateur crashé tout serait perdu, d'ou la demande de la rendre persistente. Mais si on veut garder certaine règle métier (certe pas forcément toujours cohérente mais très utilisé par les cliens) je n'ai pas le choix de faire comme cela.

En ce qui concerne les 2 utilisateurs simultanés, comme je l'ai précisé chaque utilisateur possède sont propre compte et ses propres données il y un champs discriminant sur chacune des lignes et un seul utilisateur n'a le droit de se connecter qu'une seule et unique fois à l'application donc aucun problème d'accès concurrentiel, et vu qu il s'agit d'une grille de passage de commande, je doute fort que 2 utilisateurs s'amuse à se connecter et à faire n'importe quoi avec si cela était permis

la demande initial était de pouvoir trier la liste des produits commandé et si la personne en ajoute dans la grille ils doivent êtres ajoutés à la fin sans tenir compte du tri précédemment sélectionné car beaucoup de client se sont plein que lors de l'ajout de plusieurs produits en meme temps, si la personne avait trié par ordre alphabétique, le produit commencant par la lettre A serait sur la premiere page, ceux par V sur la 20eme etc...(ce qui parrait logique si on tien compte du tri) d'ou l utilité de les avoirs en fin de liste systématiquement pour les retrouver rapidement, et les clients veulent garder l'ordre du tri des lignes précédente.
voila pourquoi je n'ai pas d'autre choix.

je comprends tout a fait vos remarques sur les accès concurrentiel et autres mais dans mon cas pas de souci la dessus. si j'en suis arrivé là c'est vraiment apres avoir retourné le truc dans tous les sens.

j'attends la version 9.2 de postgres pour pouvoir faire les 2 premiers requetes en 1 seule (create table ... as select ....)