LIMIT sur un "faux GROUP BY"

[dorian53]

Bonjour,

Question récurrente visiblement...
Est-il possible de faire un LIMIT sur un "faux GROUP BY" ?

Exemple d'un résultat de requête sur une jointure.

Code :

1
2
3
4
5
SELECT user_id, tas_id
FROM user 
INNER JOIN task
ON user_id = use_id
WHERE...

Code :

1
2
3
4
5
6
7
8
9
[USER] [TASK]
  1        1
  1        2
  1        3
  2        1
  2        2
  3        1
  4        1
  4        2

L'objectif est de récupérer seulement les résultats concernant les deux premiers utilisateurs.

Code :

1
2
3
4
5
6
[USER] [TASK]
  1        1
  1        2
  1        3
  2        1
  2        2

Il faut imaginer qu'il existe 50 conditions WHERE au niveau de TASK dans la requête.

Une solution, une idée ? Merci

Dorian

[SQLpro]

La solution est simplissime avec les fonctions de fenêtrage :

Code :

1
2
3
4
5
6
7
8
9
10
SELECT *
FROM
(
SELECT user_id, tas_id...,
       ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY tas_id) AS N
FROM   ....
       ...
WHERE  ...
) AS T
WHERE N <= 3

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

Sauf Que MySQL, cet Ersatz de SGBDR ne les implémente toujours pas !!!
Bref, passez à PostGreSQL... Vous aurez moins d'emmerde et en plus c'est gratuit, alors que MySQL est payant !

A +

[David55]

On aurait peut être pu écrire ceci aussi (certainement beaucoup moins bien):

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
SELECT user_id, tas_id
FROM user 
INNER JOIN task
ON user_id = use_id
WHERE...
 
AND user_id ON 
(
SELECT user_id
FROM user
INNER JOIN task
ON user_id = use_id
WHERE...
GROUP BY user_id
LIMIT 2
)

[CinePhil]

L'objectif est de récupérer seulement les résultats concernant les deux premiers utilisateurs.

Code :

WHERE user_id < 3

[dorian53]

Oui David55, je crains qu'il n'y ait pas d'autres solutions.

CinePhil, les deux premiers utilisateurs du jeu de résultats (pas par rapport aux id), et de toute manière on est obligé de conserver le WHERE sur TASK.

Merci à vous

[CinePhil]

Envoyé par dorian53

CinePhil, les deux premiers utilisateurs du jeu de résultats (pas par rapport aux id),

Qu'est-ce qui détermine que ce sont les deux premiers ?

et de toute manière on est obligé de conserver le WHERE sur TASK.

Il faut imaginer qu'il existe 50 conditions WHERE au niveau de TASK dans la requête.

Ça fait beaucoup ! On peut avoir la requête complète ?

[dorian53]

Envoyé par CinePhil

Qu'est-ce qui détermine que ce sont les deux premiers ?

C'est bien ça mon problème, j'aimerais pouvoir faire un

Code :

LIMIT 0, 2 sur un GROUP BY user_id

Pour répondre à la logique de l'ordre, peu importe, uniquement l'ordre du résultat de la requête. C'est pour faire de la pagination par USER.

Envoyé par CinePhil

Ça fait beaucoup ! On peut avoir la requête complète

C'est pour l'exemple d'un moteur de recherche et poser la problématique pour ne pas qu'on me propose une sous requête avec un IN comme solution.

[CinePhil]

La pagination, c'est de la présentation. C'est donc le boulot du logiciel, pas du SGBD !

Si ta requête retourne dans l'ordre {12, 24, 25, 28...}. Tu vas afficher les données de 12 et de 24. Puis avant que l'utilisateur ne demande la page suivante, de nouvelles données sont arrivées qui font que maintenant la requête donne dans l'ordre {3, 12, 15, 24, 25, 27...}. Tu vas afficher quoi ? 15 et 24 alors que l'utilisateur a déjà vu 24 ? 3 et 12 parce que maintenant ce sont les deux premiers et alors que 12 a déjà été vu par l'utilisateur ?

Il faut que le logiciel récupère la totalité du résultat de la requête, affiche les résultats de la première page et mémorise en session le jeu de résultats et là ou il en est de la pagination.

Quant au "moteur de recherche" tellement à la mode, il existe chez MySQL la recherche FULLTEXT qui peut éviter d'avoir un WHERE à rallonge.

[dorian53]

La session est intéressante mais pas sur plusieurs centaines de millier de résultats (c'est mon cas). Je ne peux pas tout retourner à chaque fois et réaliser le traitement côté code, c'est très lourd. Donc dans ton exemple, oui on ré-afficherait 15-24.

Le "moteur de recherche" est un formulaire qui propose plusieurs paramètres, donc pas de FULLTEXT envisageable trop de critères sur des dates, intervalles, sum, etc... ça reviendrait à ré-écrire un moteur de requêtes pour générer la bonne recherche (et en plus fulltext n'existe pas en innoDb, je serais obligé de faire une table à part).

[CinePhil]

Tu ne veux toujours pas donner ta vraie requête et son objectif ?
On ne peut pas t'aider davantage sans plus de renseignements.

[dorian53]

C'est pas que je ne veux pas, c'est qu'elle n'apporte rien au problème.
La requête est construite par le code il y a plus de 100 lignes et x jointures qui ne font que compliquer la résolution d'un problème aussi simple que :

J'AI DES THEMES ET DES LIVRES (1 livre = 1 thème, 1 thème = n livres),
JE VEUX PAGINER LES LIVRES PAR THEME (10 PAR 10) QUI REPONDENT AUX CRITERES DE LIVRE SUIVANTS...

THEME 1
> Livre 1
> Livre 2
> Livre 3
> Livre ..
> Livre N
THEME 2
> Livre 42
THEME 10
> Livre 4

Exactement pareil que USER et TASK.