Discussion :

[knoodrake]

Bonjour,

J'ai donc ma gentille requete:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT t1.name, t2.name AS nameT2
FROM table1 AS t1
LEFT JOIN table3 AS t3 ON t3.t1_id = t1.id
LEFT JOIN table2 AS t2 ON t3.t2_id = t2.id
WHERE t1.id IN (1,2);

qui me donne, et c'est en effet ce que je veux:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
+--------+-------------+
| name   | nameT2      |
+--------+-------------+
| foo    | XXX         | 
| foo    | YYYYY       | 
| foo    | ZZZZZZZ     | 
| foo    | WWWWWWWWWW  | 
| bar    | AAAAAAAA    | 
| bar    | TTTT        | 
+--------+-------------+

Mais pour des questions de place - car sur des requetes qui retournent beaucoup plus de colonnes et beaucoup beaucoup de lignes, ça peu finir par peser tout ça dans le code qui s'en sert - j'aimerai obtenir ça par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
+--------+-------------+
| name   | nameT2      |
+--------+-------------+
| foo    | XXX         | 
|        | YYYYY       | 
|        | ZZZZZZZ     | 
|        | WWWWWWWWWW  | 
| bar    | AAAAAAAA    | 
|        | TTTT        | 
+--------+-------------+

Pour ce faire j'ai un peu fouillé le net et j'ai trouvé cet intéréssant fil ( en anglais ): http://www.dbforums.com/showthread.php?t=927152

Mais a cause - je suppose - de mes jointures et toussa toussa et bien je n'y arrive pas du tout.

Une ( ou des ) idées ?
Merci déja d'avoir lu on post

[al1_24]

Il s'agit là de cosmétique, qui n'est pas le but du langage SQL.
C'est à l'application de se charger de la mise en forme des données.

[Alain Defrance]

Bonjour,

Tente ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
GROUP BY name
WITH ROLLUP

[pacmann]

Tout à fait d'accord, cela dit...
Si tu es sur SQL server, tu peux t'amuser avec un truc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SELECT case (row_number() over(partition by (Col1) order by untruc)) when 1 then col1 else "" end, 
col2
FROM ...

Tu définis un partitionnement qui te permet de numéroter tes enregs... et donc de savoir quand ce n'est pas le premier de la série "foo".

[knoodrake]

Heu non, ce n'est pas de la cosmétique, en tout cas pas dans mon esprit. Admettons que je rameutte des lignes de +10 colonnes, et que seule 1 des colonnes varie, alors les 9 autres seront dupliquées et si mon résultat fait pas mal de lignes, 9*pas-mal-de -lignes ça peu constituer beaucoup de place. Beaucoup de place en mémoire, beaucoup d'octets qui vont inutilement transiter de l'appli au serveur de la BD, ..

Voila pour ma défense
Sur ce, je vais voir le lien que tu m'a donné, et merci pour ta réponse.

EDIT: Hu ! j'ai eu 2 réponses entre-temps, je répondais là à la premiere

[Alain Defrance]

Moi je pense que c'est le ROLLUP qu'il te faut ...

[EDIT] Ok

[knoodrake]

J'ai éssayé avec GROUP BY et WITH ROLLUP mais ça ne marche pas. D'ailleurs pourquoi ça marcherai en fin de compte, WITH ROLLUP ne sert qu'a donner un total non ? et GROUP BY m'enlève des colonnes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
+--------+-------------+
| name   | nameT2      |
+--------+-------------+
| foo    | XXX         | 
| bar    | AAAAAAAA    |  
+--------+-------------+

( ps: la y'a pas le rollup )
( ps: Et pitite précision je suis sous mysql5)

@pacmann:
Si j'ai bien compris c'est un peu le principe de la solution utilisé à la fin du lien que j'ai mis dans mon premier post ( mais sans "partitionement" puisque mysql ) sauf que je n'arrive pas à le reproduire avec ma structure 1 < n > m

[Alain Defrance]

D'ailleurs pourquoi ça marcherai en fin de compte, WITH ROLLUP ne sert qu'a donner un total non ?

Exact, je doit confondre avec un truc désolé

[pacmann]

Désolé, j'avais pas lu le lien...

C'est quoi n et m ?

[knoodrake]

Désolé, j'avais pas lu le lien...

C'est quoi n et m ?

Ah heu c'était juste ma façon de dire que table1 "possède" n table 3 ( et n étant une table qui sert a lier les 2 autres ) désolé.
(Edit: je m'apperçois que j'ai pas été beaucoup plus clair m'enfin bref, je pourrai pas faire mieux mais c'est pas important )

[pacmann]

Ah ok, ben c'est exactement la même chose.
En fait, ta jointure te renvoie un ensemble de lignes.
Tu compares avec le même ensemble de lignes, en "restreignant" sur ta colonne à simplifier, puis il te faut définir un ordre absolu sur cette jointure.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
select case c.col > (select min(f.col)
                            from t1 d, t2 e, t3 f
                             where d.fk = e.id
                                and e.fk = f.id
                                and d.col1 = a.col1))
          then '     '
          else a.col1 end, 
c.nom
FROM t1 a, t2 b, t3c
WHERE a.fk = b.id
  and    b.fk = c.id

Bon, j'ai pas testé, et on ne parlera pas de performances...

[knoodrake]

Yipikai ! J'ai réussi. Merci à vous tous.
J'ai fait comme tu me l'a ré-expliqué pacmann. Maintenant me reste plus qu'a essayer de l'améliorer un peu si possible et surtout voir si la perte de performance est considérable ou pas

[SQLpro]

La perte de perf va être exponentielle car dans cette seconde requête vous avez un produit cartésien à faire (matrice diagonale du fait du > ) et des conditions qui ne sont pas "sargable" >. De plus le fait de mettre 6 blancs n'enlève rien au problème !

Encore une fois s'agissant de cosmétique vous allez dégrader sévèrement les performances avec une requête compliquée et difficile à maintenir !

A +

[knoodrake]

Bonjour,

Que veut dire "pas sargable" ? que la clause est re-testé a chaque fois ou quelque chose comme ça ?
Pour la perte de performances, c'est déja un poil mieux avec des jointures pour la requete principale ( mais pas pour la sous-requete ).
Ensuite je ne comprend pas pourquoi des "blancs" ( concretement, je n'ai pas mis " " mais NULL ) ne changeraient rien au problème de la taille.

Bon, en revanche c'est vrai que la requete devient complexe pour peu de chose et je galère maintenant à la "façonner" comme je l'entend, et comme ceci s'ajoute à la perte de vitesse je vais peut-être abandonner l'idée et revenir à la simpliste requete de départ, ou bien faire 2 requetes différentes ( mais c'etait la mon but premier: réduire le nombre de requetes, rapport à mon hébergement )

Quoi qu'il en soit, je suis tout de même heureux d'y être parvenu, j'ai au appris a me servir des strucures de contrôles ( ici CASE ) et d'autres choses

[fsmrel]

Que veut dire "pas sargable" ?

Vous trouverez le terme "sargable" à la page 44 du document The 1995 SQL Reunion: People, Projects, and Politics, ainsi que pas mal d'anecdotes concernant la descendance de System R (SQL/DS, DB2, ORACLE, SYBASE, etc.)
System R est le prototype relationnel qui a servi à IBM pour démontrer la faisabilité et le grand intérêt d'industrialiser un SGBDR. Ça n'était pas gagné, car le SGBD phare et néanmoins hiérarchique IMS DB/DC faisait rentrer beaucoup de sous (et ça continue...)
Vous trouverez l'histoire de System R dans le document A History and Evaluation of System R.
Vous y apprendrez que lors de la phase 1 du prototype (1976-1977), ses deux principaux composants étaient le RDS (Relational Data System) et le RSS (Research Storage System). Le RDS jouait le rôle du mathématicien-logicien et le RSS celui de l'informaticien traditionnel. Une requête SQL comportant des prédicats complexes ou tordus était dite "non sargable" et du ressort du RDS qui la décortiquait et transmettait au RSS quelque chose de compréhensible par ce dernier. Par contre, si le RSS était capable d'analyser la requête SQL initiale, celle-ci était qualifiée de "sargable" ("search argument-able"), le RDS ne s'y intéressait pas et laissait donc faire le RSS. Il en résultait un gain en consommation CPU.
Ce binôme perdure chez IBM (SQL/DS, DB2), à ceci près que le RSS a été rebaptisé DM (Data Manager) et que le terme "sargable'" a été transformé en "stage 1". Un prédicat qui n’est pas "stage 1" est "stage 2" (non sargable). Il est évidemment recommandé de développer des requêtes sargables, mais il est surtout conseillé de développer des requêtes indexables, c'est-à-dire pour lesquelles le SGBD peut utiliser un index.
Par exemple, dans le cas de DB2, le prédicat "colonne_x LIKE '"%knoodrake" n’est pas indexable alors qu’il est sargable, ce qui n’empêchera pas malgré tout l’utilisateur de contempler son sablier et de compter les minutes ou les heures avant d’obtenir une réponse, si entre temps son écran n'a pas volé par la fenêtre...

[knoodrake]

Oula Merci pour cette réponse très complète et instructive.
Je comprend bien le sens de ce terme et même plus maintenant.
Je vais aussi consulter les deux textes qui ont l'air intéressants.

Pour ce qui est du "%knoodrake" c'est une des rares choses que j'avais déja réussi à comprendre ( ca n'est pas indexable du fait de la structure en arbre des index de ce que j'en ai déduit )
D'ailleurs, et en guise de conclusion pour ce post qui s'attarde je vais en profiter pour poser une dernière petite question annexe, après promis je met [RESOLU]:
J'avais lu un jour l'astuce pour avoir des requetes "%foo" indexable de dupliquer la table en question mais avec les son contenu inversé ( "oof" au lieu de "foo" ) pour ensuite pouvoir rechercher "oof%".
A part que le temps et la place sont un poil plus que doublés, est-ce une technique viable, courrament utilisé et n'y a-t-il pas d'alternative ?

Je te remercie encore fsmrel pour cette exelente réponse ainsi que SQLpro, pacmann, al1_24 et kazou pour m'avoir aidé et appris.