Discussion :

[clavier12AZQSWX]

bonjour,

j'ai cherché dans les tutos de dvp.net si il y avait une telle requête en exemple (type tableau croisé dynamique) ou dédiées aux dates/période mais je n'ai pas trouvé donc je pose la question ici en recherche d'aide ou de piste.

J'ai une liste de personne affectées à des groupes avec une date de début, de fin, (et un nom de groupe) :



j'ai déjà construite cette vue (si il faut ajouter-concatainer l'année+semaine, je peux le rajouter au cas où mais je ne vois pas l'utilité encore à part pour du classement car les n° de semaine ont des homonymes annuelles.)

je cherche à avoir en résultat SQL , un tableau fait actuellement à la main dans excel qui se présente ainsi :

à gauche en verticale : la liste des personnes
en haut en horizontale : la liste des n° de semaines en première ligne (et la date de début et de fin du numéro de semaine en seconde ligne mais c'est pa obligatoire)

en croisement des lignes/colonnes j'ai donc le nom du groupe

Pensez-vous qu'un tel résultat ressemblant à un tableau croisé dynamique .

J'ai du mal à croire que je vais devoir écrire une clause SELECT avec les 52-53 semaines en champs listés dans la requête !

ça doit être un cas d'école mon problème, à moins que ce ne soit pas possible en BD mais uniquement en tableur.

bonne journée

[al1_24]

Ce que tu cherches à faire s'appelle en SQL un PIVOT.
Bien que cette opération ait été normalisée, chaque éditeur l'adapte à sa sauce voire ne l'implémente pas du tout. A toi de voir comment cela est pris en charge dans le SGBD que tu utilises.

Dans tous les cas, le langage SQL réclame (et encore plus les applicatifs qui utilisent le résultat des requêtes) que le nombre et la position des colonnes soient définis. Si tu cherches à créer une requête avec un nombre de colonnes et des contenus variables, il va falloir que tu la construises dynamiquement dans ton applicatif.

[Séb.]

Tu ne précises pas ton SGBD, et ni le rendu exact attendu.

Avec DuckDB tu peux faire :

with ds (pers_id, pers_grp_id, date_debut, date_fin) as (
	values
		( 862,   1, '2023-10-05', '2025-10-31'),
		(1050, 278, '2025-01-23', '2025-06-06'),
		(1145, 161, '2025-05-14', '2026-04-10'),
		(1097, 372, '2025-05-12', '2025-06-26'),
		(1125, 372, '2025-05-26', '2025-05-26'),
		( 919, 251, '2025-06-16', '2025-08-29'),
		(1089, 279, '2025-06-30', '2026-06-01'),
)
pivot ds
on strftime(date(date_fin), '%G-W%V')
using list(distinct pers_grp_id)
group by pers_id
order by all asc;

Ce qui donnera :



Si tu veux toutes les colonnes entre date_debut et date_fin alors il faudra une table utilitaire calendrier ou une CTE récursive.

[clavier12AZQSWX]

bonjour Séb.,

déjà merci pour la découverte de DuckDB , je connaissais pas et ça a l'air pratique & easy pour un projet future...


mon sgbd est mysql 5.7.42-log, je ne voulais pas le spécifier pour rester dans un sql pur.
Mon rendu est exactement ce que tu as proposé en seconde images.

Je vais me renseigner pour voir si l'instruction 'pivot' est dispo dans mysql...

je ne veux pas toutes les semaines, seulement celles où les date_debut est sont concernées. donc pas besoin d'une table avec les toutes les dates/semaines.
J'ai aussi besoin de totaux en bout de ligne et de colonne mais ça je le ferai en code PHP après le rendu (ne me dites pas que les sgbd moderne permettent ça, ce serait incroyable d'avoir des coupures de groupes avec totaux comme dans le reporting ireport....)

[escartefigue]

Bonjour,

MySQL 5.7 est une version obsolète, qui ne connait non seulement pas les pivots, mais pas non plus les CTE et donc pas les requêtes récursives, pas plus que les fonctions OLAP et plein d'autres choses encore...
La V8 de MySQL ne connait pas non plus l'ordre PIVOT et toujours pas les jointures full outer , mais a au moins intégré les CTE et certaines fonctions OLAP.
Pourquoi rester sur cette vieille version 5.7 ?

[clavier12AZQSWX]

Bonjour,

MySQL 5.7 est une version obsolète, qui ne connait non seulement pas les pivots, mais pas non plus les CTE et donc pas les requêtes récursives, pas plus que les fonctions OLAP et plein d'autres choses encore...
La V8 de MySQL ne connait pas non plus l'ordre PIVOT et toujours pas les jointures full outer , mais a au moins intégré les CTE et certaines fonctions OLAP.
Pourquoi rester sur cette vieille version 5.7 ?

parce que l'hébergeur l'impose :-)

bon si j'ai bien compris, je vais devoir faire une partie avec ses CASE qui va rendre illisible la requête tellement elle sera longues...

si je construit une vue secondaire, ya pas moyen que je fasse ce pivot avec un produit cartésien ?

En fait le but (si je comprends l'objectif de ma collègue), c'est d'avoir le Nb de personnes par groupe par n° de semaine.

grp_id s1 s2 s3 s52 s53
1 12 15 16 18
2 12 65 69 0 45
3 47 0 0 0

Si je peux m'en sortir sans avoir à faire 52 CASE, ce serait super, quitte à faire 1 ou 2 vues intermédiaires

je viens de me créer un vue avec les semaines concernées :

Code sql :

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

1
2
3
4
5
6
7
8
CREATE OR REPLACE VIEW semaines_concernees AS
SELECT DISTINCT WEEK(date_debut) as semaine
FROM matable_effectifs
UNION 
SELECT DISTINCT WEEK(date_fin) as semaine
FROM matable_effectifs
ORDER BY 1
;

qui me donne mes lignes de n° de semaine...

Je sais pas pourquoi mais ya un truc dans ma tête qui me dit qu'avec un group by sur une jointure cartésienne (pas sûr du nom, ça remonte à mes études) , c'est possible....

[escartefigue]

Bonjour,

MySQL 5.7 est une version obsolète, qui ne connait non seulement pas les pivots, mais pas non plus les CTE et donc pas les requêtes récursives, pas plus que les fonctions OLAP et plein d'autres choses encore...
La V8 de MySQL ne connait pas non plus l'ordre PIVOT et toujours pas les jointures full outer , mais a au moins intégré les CTE et certaines fonctions OLAP.
Pourquoi rester sur cette vieille version 5.7 ?

parce que l'hébergeur l'impose :-)

La première version commerciale de la V8 date de 2017, il serait temps que cet hébergeur s'y mette !
Voir ICI

bon si j'ai bien compris, je vais devoir faire une partie avec ses CASE qui va rendre illisible la requête tellement elle sera longue...

GROUP_CONCAT permet de présenter à l'horizontale une liste de valeurs selon un critère de regroupement
Sinon, à défaut d'instruction PIVOT, plutôt que de monter une usine à gaz, il est préférable de faire une requête simple et de modifier la présentation coté application.