Discussion :

[Cedrati]

Bonsoir,

Je suis en train de faire l'interface graphique d'un projet en Database, et la dernière partie dudit projet est l'exécution de requêtes pour le moins assez complexes. Un exemple de requête est :
Lister les 10 artistes qui ont le plus grand nombre de tracks apparaissant sur des compilations. Une compilation est un média (CD, Vinyl, Digital, etc) qui contient des tracks associés à plusieurs artistes (en gros pas un album).

Mon code SQL pour cette requête est le suivant :

create index track_medium on track(IDMedium)
create index artistind_track on artist_track(IDTrack)

create temporary table compilation(
select IDMedium
from artist_track join track using(IDTrack)
group by IDMedium
having count(distinct IDArtist)>1);

create temporary table temp_tracks(
select distinct IDTrack
from compilation join track using(IDMedium));

select IDArtist, ArtistName
from temp_tracks join artist_track using(IDTrack) join artist using(IDArtist)
group by IDArtist
order by count(*) desc
limit 10

Ma question est la suivante :
What da F ? Plus sérieusement, j'ai déjà affiché le résultat d'une requête (un simple select *) dans une JTable, mais là je ne sais pas comment faire pour une bonne grosse requête SQL comme celle-là, sachant que j'ai une autre quinzaine qui attend d'être traitée de la même manière que celle-ci à peu près.

N'hésitez pas si besoin de plus d'infos concernant la structure de la BD ou autre.

Une bonne soirée à tous.

[freeway57]

C'est quoi concrétement ton problème ? Tu ne veux pas récupérer toutes les colonnes que te ressort la requête mais seulement quelques une ?

Je ne vois pas trop où est le problème..

[tchize_]

la création de temporary tables ne me semble pas très propre d'un point de vue performances Les SGBD ont en général un moyen pour s'en passer et tout optimiser dans une seul requête.

Par exemple, sous oracle, tu as le with (.......) as. Qui a l'avantage de laisser l'opportunité au SGBD de tenir compte, dès le départ, de ton limit et des jointures additionnelles.

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
with compilation as (
select IDMedium
from artist_track join track using(IDTrack)
group by IDMedium
having count(distinct IDArtist)>1),
temp_tracks as (
select distinct IDTrack
from compilation join track using(IDMedium))
select IDArtist, ArtistName
from temp_tracks join artist_track using(IDTrack) join artist using(IDArtist)
group by IDArtist
order by count(*) desc
limit 10

Pour le reste, moi non plus, je ne vois pas quel est ton problème

[Cedrati]

En gros mon problème était d'afficher le résultat de deux requêtes totalement différentes dans une seule JTable i.e. pour un artiste entré par le user, afficher tous ses albums et les genres auquel il appartient.

freeway57 Ma demande n'était en effet pas très claire mais j'avais une deadline assez proche et il se faisait assez tard donc ..
Ceci dit j'ai résolu le problème, même si c'était pas très joli joli niveau esthétique. J'ai utilisé des ResultSet pour chaque requête (à part pour les créations d'index bien sûr) et affiché le tout dans une JTable.

tchize_ En se partageant les tâches, je ne m'occupais que de l'interface graphique. L'implémentation des requêtes était faite par mon binôme, qui utilisait MySQL et pas Oracle. Mais merci de l'input, je suis sûr que ça servira très prochainement

[tchize_]

si ça peux rentrer ensemble dans une seule table, ça peut être produit par une seule requête SQL

[Cedrati]

si ça peux rentrer ensemble dans une seule table, ça peut être produit par une seule requête SQL

Oui j'imagine bien, mais vu que j'avais jamais fait de GUI database avant j'y suis un peu allé à la bourrin côté implémentation, mais tout est bien on a eu 96% donc all good (le code n'était pas inclus dans le rendu).

Aussi pour revenir à ta réflexion, tu dis qu'on peut mettre 2, 3 tables temporaires + la requête finale dans une seule String et ça fonctionnerait ?

[tchize_]

Non, je dit que si c'est juste pour faire un query juste après sur les tables temporaires, ça n'a aucun intérêt de les créer, autant utiliser directement une seule query. C'est surtout intéressant pour les performance

Prenons un exemple simple:

tu crée un table temporaire A, qui résume 100.000 données en 2000 données
tu crée un autre table temporaire B qui résume 30.000 données en 100 données
tu faire une requête joignant A et B et qui sort 10 lignes.

Ou,

tu crée un requête compliqué sortant les 10 lignes directement.

La première à toutes les chances de brasser 130,000 données.
La deuxième à plus de chance de brasser très peu de données.

Par expérience, c'est ce qui peut faire la différence entre une requête qui met 3 minutes et une requête qui met 5 secondes

Les tables temporaires, c'est pas destinée à l'usage que tu en as fait (en tout cas pas sur oracle). Sur d'autres SGBD peut-être que c'est la bonne pratique. Dans tous les cas, avec jdbc, vaut mieux tout mettre dans une seule query, c'est chiant de devoir couper la query en plusieurs preparedStatements

[Cedrati]

Non, je dit que si c'est juste pour faire un query juste après sur les tables temporaires, ça n'a aucun intérêt de les créer, autant utiliser directement une seule query. C'est surtout intéressant pour les performance

Prenons un exemple simple:

tu crée un table temporaire A, qui résume 100.000 données en 2000 données
tu crée un autre table temporaire B qui résume 30.000 données en 100 données
tu faire une requête joignant A et B et qui sort 10 lignes.

Ou,

tu crée un requête compliqué sortant les 10 lignes directement.

La première à toutes les chances de brasser 130,000 données.
La deuxième à plus de chance de brasser très peu de données.

Par expérience, c'est ce qui peut faire la différence entre une requête qui met 3 minutes et une requête qui met 5 secondes

Les tables temporaires, c'est pas destinée à l'usage que tu en as fait (en tout cas pas sur oracle). Sur d'autres SGBD peut-être que c'est la bonne pratique. Dans tous les cas, avec jdbc, vaut mieux tout mettre dans une seule query, c'est chiant de devoir couper la query en plusieurs preparedStatements

Ce n'est clairement pas le plus agréable, mais vu que c'était ma première fois sur du jdbc et que je faisais confiance au binôme pour les requêtes j'y ai pas pensé 2 fois, parce que c'était un projet assez lourd (chargé donc, pas chiant ).

Ceci dit pour les temp tables c'était plus pour rendre facile à voir pour les correcteurs, c'est surtout les index qui amélioraient nos performances, vu qu'on avait des fichiers CSV de +500Mo (ce qui fait facilement plus d'un million d'entrées).