Discussion :

[PapyJP]

Bonjour à tous
Je suis parvenu à faire de l'informatique pendant 50 ans sans avoir à utiliser les bases de données relationnelles, mais je me trouve maintenant dans la situation de devoir "un peu" m'en servir.
Je me permets donc de vous poser une question de débutant.
Je dois retrouver des informations qui sont contenues dans de nombreuses tables pour afficher ce résultat https://www.alma-musica.net/html/repertoire.php
Comme vous pouvez le voir, il s'agit de données hiérarchiques:
Saisons
Programmes
Auteurs
Œuvres
Mouvements (pour certaines œuvres)
Fichiers de travail

Ma question de béotien en la matière:
dois-je écrire une seule requête qui me renverra quelques 1280 lignes si j'ai bien compté, avec des informations similaires redondantes en pagaille ou est-il considéré comme légitime de récupérer ces données de façon fractionnée, ce qui conduirait à quelques centaines de requêtes?

Merci de bien vouloir partager votre expérience.

[escartefigue]

bonjour,

A priori, le besoin est de faire la liste des événements musicaux par saison, avec, pour chaque événement, un certain nombre d'informations telles que l'auteur, la partition, un texte descriptif, une image...

Il faut donc créer une seule requête en utilisant des jointures entre les tables SAISON, EVENNEMENT, AUTEUR, OEUVRE etc...

Si vous faites plein de requêtes séparées, ça revient à livrer le résultat sous forme de puzzle dans sa boite : tous les morceaux sont présents, mais dans le désordre...

[PapyJP]

bonjour,

A priori, le besoin est de faire la liste des événements musicaux par saison, avec, pour chaque événement, un certain nombre d'informations telles que l'auteur, la partition, un texte descriptif, une image...

Il faut donc créer une seule requête en utilisant des jointures entre les tables SAISON, EVENNEMENT, AUTEUR, OEUVRE etc...

Si vous faites plein de requêtes séparées, ça revient à livrer le résultat sous forme de puzzle dans sa boite : tous les morceaux sont présents, mais dans le désordre...

Merci de votre réponse
Vous avez bien compris le problème, et c'est ce que j'ai tenté de faire.
Ecrire cette requête n'est pas un problème très difficile et j'y suis parvenu assez rapidement.
J'ai effectivement essayé cette solution avec PHPmyAdmin
PHPmyAdmin a émis des warnings sur la taille attendue des résultats.
Si j'ai bien compris obtenir de très longs résultats nécessite une configuration spéciale de la base de données, ce qui sort de mes compétence.
J'ai donc réduit l'ambition de la requête en la limitant à un seul programme et j'obtiens quelque chose de gérable.

Je ne comprends pas votre remarque sur "les morceaux sont présents dans le désordre".
La table la plus importante dans ce domaine s'appelle "ProgItems", avec d'un côté une référence au programme, d'autre part une référence à l’œuvre, et un champ "rank" qui indique l'ordre dans lequel les pièces sont jouées pour un programme donné (sachant que la même œuvre peut être jouée dans plusieurs programmes, et dans un ordre différent). La requête donne donc le résultat avec les pièces dans l'ordre.
Ce qui est de toute façon le résultat de toute requête SQL, c'est la répétition de champs identiques sur de nombreuses lignes. Pour moi quine suis pas familier avec cette techno, ça me semble un peu bizarre, mais je vais arriver à gérer.
Si ça vous intéresse, voici l'état actuel de la requête.
Je pense que c'est lisible, les noms des tables et des champs en "computer english" sont assez clair je l'espère.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
SELECT DISTINCT
	p.title AS programTitle,
	p.plannedDate AS programDate,
	pdoc.rank AS docRank,
	pdoc.title AS docTitle,
	pdoc.link AS docLink,
	pi.rank AS rank,
	a.firstName,
	a.lastName,
	a.birth,
	a.death, 
	a.url AS authorURL,
	IF(pi.title IS NULL, w.title, pi.title) AS title,
	IF(pi.solo IS NULL, w.solo, pi.solo) AS solo,
	IF(pi.choir IS NULL, w.choir, pi.choir) AS choir,
	IF(pi.instrument IS NULL, w.instrument, pi.instrument) AS instrument,
	pi.comments AS comments,
	wf.link AS fileLink,
	wf.private AS privateFile,
	wf.type AS fileType,
	wft.*
 
FROM ProgItems AS pi
LEFT JOIN Works AS w
	ON w.authorID = pi.authorID AND w.workID = pi.workID AND w.mvtID = pi.mvtID
LEFT JOIN Authors AS a
	ON a.authorID = pi.authorID
JOIN Programs AS p
	ON p.progID = pi.progID
LEFT JOIN ProgDocs AS pdoc 
	ON pdoc.progID = p.progID
LEFT JOIN WorkFiles AS wf
	ON wf.authorID = w.authorID AND wf.workID = w.workID and wf.mvtID = w.mvtID
LEFT JOIN WorkfileTypes AS wft
	ON wft.type = wf.type
WHERE
	pi.progID = 'Bastille2020'
ORDER BY pi.rank,
		 wft.id 
LIMIT 1000
;

Comme de toute façon les données retournées doivent être traitées pour mise en forme, le images sont ajoutées lors de ce traitement.

[escartefigue]

Quand je disais qu'avez plusieurs requêtes on a les morceaux du puzzle mais dans le désordre, j'aurais peut être dû dire sans le plan permettant des les assembler

Si on se limite à un exemple simple comportant deux tables (on dira que pour l'exemple, une œuvre n'a qu'un seul compositeur)
CO_compositeur (CO_ident, CO_nom, CO_date_naissance)
OE_oeuvre(OE_ident, OE_nom, OE_date_creation, CO_ident#)

Si je dois faire la liste des compositeurs et de leurs oeuvres, en utilisant une jointure, j'aurai forcément autant de fois les attributs d'un compositeur que celui-ci possède d'oeuvres dans la table des oeuvres, c'est tout à fait normal, mais j'aurai sur la même ligne les oeuvres correspondant à leur compositeur.

Si je fais deux requêtes distinctes, l'une pour les compositeurs, l'autre pour les oeuvres, puisque c'était l'une des deux solutions envisagées dans votre question initiale, alors je contraint l'utilisateur à assembler les deux résultats manuellement en consultant la clef étrangère CO_ident dans la liste des oeuvres pour aller rechercher les informations correspondantes dans la liste des compositeurs... Pas terrible comme service rendu

[PapyJP]

Merci de votre message
Jusqu'à présent je travaillais uniquement sur des objets dont les propriétés se trouvaient dans des fichiers xml.
Chaque objet possède un attribut unique, ses données sont uniques, etc.
Le problème c'est que je ne peut pas transmettre la gestion d'une telle "base objet" à d'autres personnes: depuis les années 90, tout le monde utilise des RDBS, je suis donc contraint à faire une nouvelle version de mes outils utilisant un RDBS.
Ce que je constate en utilisant le SQL, c'est que même si une donnée est unique dans la base, on la récupère de nombreuses fois dans le résultat d'une requête, et que pour reconstituer mes objets je dois partir de la donnée de plus bas niveau (ici le fichier d'une partition) et remonter de base en haut pour retrouver l'objet oeuvre dont le fichier de base est la partition, puis l'objet programme dont cette oeuvre fait partie.
Ce n'est pas un problème technique, bien entendu, c'est simplement un changement d'approche qui me perturbe énormément.
A voir le nombre de lignes qui contiennent les mêmes données sauf une je me demande si je ne fais pas totalement fausse route.

Quand vous dites

Si je dois faire la liste des compositeurs et de leurs oeuvres, en utilisant une jointure, j'aurai forcément autant de fois les attributs d'un compositeur que celui-ci possède d'oeuvres dans la table des oeuvres, c'est tout à fait normal, mais j'aurai sur la même ligne les oeuvres correspondant à leur compositeur.

ça me confirme que c'est effectivement comme ça que ça doit fonctionner, il faut que je me fasse à cette approche...

[escartefigue]

Le résultat de la requête compositeur oeuvre sera quelque chose comme :

NOM	PRENOM	OEUVRE	ANNEE
MOZART	WOLFGANG	symphonie n°25	1773
MOZART	WOLFGANG	symphonie n°28	1773
MOZART	WOLFGANG	symphonie n°29	1774
MOZART	WOLFGANG	Les Noces de Figaro	1786
BERLIOZ	HECTOR	La Damnation de Faust	1846
BERLIOZ	HECTOR	Roméo et Juliette	1839

nom et prénom sont bien sûr répétés autant de fois qu'il y a d'oeuvre, mais c'est nécessaire, sinon comment savoir à qui appartient l'oeuvre ?

[PapyJP]

Cette façon de traiter les problèmes est celle des SQBDR, il y a plein d'autres façons de traiter les même problème, apparemment moins gaspilleuses de ressources machine, mais il est vrai que ce n'est plus la principale contrainte aujourd'hui.

Quand j'ai vu que ma requête, pour un seul concert, finissait par générer environ 200 lignes de plus de 20 champs chacune, avec pratiquement pour chaque ligne un seul champ qui diffère du précédent, je me suis dit que mon ignorance m'avait conduit en dehors des clous.

Apparemment il faut que je m'habitue à ce qui pour moi ressemble à une avalanche de données dans laquelle seules certaines sont pertinentes.

Une technologie de type objet vous donne la liste des œuvres sous la forme d''index dans la table des œuvres, chaque œuvre ayant un index dans la table des auteurs et une liste d'index dans la table des fichiers correspondant à l’œuvre.
Contrairement à ce que l'on faisait dans les anciennes bases de données, les données ne sont pas répétées, mais ce qui est stocké est structuré.

Pour reconstruire une structure cohérente à partir de l'avalanche de données reçues en réponse à ma requête j'ai passé une bonne partie de mon après midi à faire un programme "archéologique" qui permette à partir des fragments reçus de reconstituer l'architecture de l'ensemble.
J'ai dû m'interrompre, je continuerai demain.

Encore une fois il n'est pas question de "bien" ou "mal", c'est pour moi un changement par rapport à une approche efficace que j'ai suivie pendant des dizaines d'années.

Merci pour l'aide que vous voulez bien m'apporter

[PapyJP]

La nuit permettant d'éclaircir les idées, je pense que l'écueil que je rencontre actuellement vient de ma méconnaissance du SQL.

Voici le schéma simplifié des données relatives aux "programme"


Un programme peut avoir d'une part des documents attachés, d'autre part des œuvres qui sont des éléments du programme
Il s'agit de deux objets tout à fait distincts et qui n'ont en commun que d'être attachés au même programme.

Le peu de SQL que je sais faire ne me permet que de récupérer dans des colonnes distinctes les données de ces objets.
En ce qui concerne les œuvres, je reçois une ligne par "fichier d’œuvre" (partition, enregistrement, etc.) ce qui fait déjà beaucoup
Mais comme les documents occupent des colonnes distinctes, ces lignes sont multipliées par le nombre de documents, ce qui devient difficile à gérer.

Ce que j'aimerais recevoir à la suite c'est
- une ligne par document
- suivi du nombre de lignes nécessaires aux œuvres

Je n'ai aucune idée sur la façon de faire cela, ni même si c'est faisable, l'alternative étant de faire deux requêtes distinctes, mais ce n'est pas cette voie que vous m'avez recommandé d'emprunter.

Pouvez vous m'aider dans cette approche?

[PapyJP]

Après y avoir passé l'essentiel de la journée je suis parvenu à retrouver les données permettant de générer la page https://www.alma-musica.net/html/private/repertoire.php avec seulement 3 requêtes:
1) une requête principale permettant re trouver les informations générales de tous les programmes (titre et autres informations générales) et tout ce qui concerne les œuvres au programme
2) une requête permettant de retrouver les informations concernant les documents, lesquels sont réintégrés dans les objets "programmes") en PHP
3) une requête permettant de retrouver à part (c'était ce que je voulais faire) les informations concernant les auteurs.

Je vous remercie de vos conseils et je marque ce sujet comme résolu.

[SQLpro]

Bonjour à tous
Je suis parvenu à faire de l'informatique pendant 50 ans sans avoir à utiliser les bases de données relationnelles, mais je me trouve maintenant dans la situation de devoir "un peu" m'en servir.
Je me permets donc de vous poser une question de débutant.
Je dois retrouver des informations qui sont contenues dans de nombreuses tables pour afficher ce résultat https://www.alma-musica.net/html/repertoire.php
Comme vous pouvez le voir, il s'agit de données hiérarchiques:
Saisons
Programmes
Auteurs
Œuvres
Mouvements (pour certaines œuvres)
Fichiers de travail

Ma question de béotien en la matière:
dois-je écrire une seule requête qui me renverra quelques 1280 lignes si j'ai bien compté, avec des informations similaires redondantes en pagaille ou est-il considéré comme légitime de récupérer ces données de façon fractionnée, ce qui conduirait à quelques centaines de requêtes?

Merci de bien vouloir partager votre expérience.

Sans le contexte difficile de vous répondre. De plus votre post n'est pas à sa place ici. Avant de choisir MySQL qui est la pire merde au niveau des SGBD on commence par étudier la modélisation de la base et on choisit le SGBD adapté après....
Il aurait fallu poser votre question dans le forum général des bases de données.Par exemple : Forum / Bases de données / Décisions SGBD / Débuter
https://www.developpez.net/forums/f9...-sgbd/debuter/

À vue de nez je suppose qu'il s'agit de gérer un festival... Me trompe-je ?

CONTEXTE :
l'application va t-elle être sur le web ?
Si oui, en totalité ou pour partie ?
Si pour partie laquelle ?

La question de béotien va être répondu en fonction des questions que je vous pose !

A +

[PapyJP]

Sans le contexte difficile de vous répondre. De plus votre post n'est pas à sa place ici. Avant de choisir MySQL qui est la pire merde au niveau des SGBD on commence par étudier la modélisation de la base et on choisit le SGBD adapté après....
Il aurait fallu poser votre question dans le forum général des bases de données.Par exemple : Forum / Bases de données / Décisions SGBD / Débuter
https://www.developpez.net/forums/f9...-sgbd/debuter/

Je n'ai pas le choix du gestionnaire de base de donnée. C'est et cela restera celui de notre hébergeur.

À vue de nez je suppose qu'il s'agit de gérer un festival... Me trompe-je ?

Oui (vous vous trompez) Non (il ne s'agit pas de gérer un festival).

CONTEXTE :
l'application va t-elle être sur le web ?
Si oui, en totalité ou pour partie ?
Si pour partie laquelle ?

Ce que vous qualifiez d'application n'est que la transposition en ligne de la gestion des données d'une association qui se fait sur mon PC depuis 1999.
Les données sont gérées dans des fichiers Excel, transférées sur le serveur sous forme de fichiers xml et exploitée sur le serveur par des programmes PHP.
Ce mécanisme fonctionne de façon très efficace, mais je ne peux pas le transmettre à d'autres personnes car il s'agit d'une techno trop "propriétaire".
Je suis donc conduit à remplacer ma base de données objet propriétaire par l'outil standard de nos jours (SGBDR)

La question de béotien va être répondu en fonction des questions que je vous pose !

A +

Je suis béotien quant à l'utilisation des SGBDR, j'ai derrière moi 50 ans d'informatique :développement de système d'exploitation, participation à la normalisation de procédures de télécommunication, direction de projets de recherche européens, et j'en passe, dont la définition et la réalisation de l'outil de contrôle des projets clientèle au niveau Europe/Moyen-Orient/Afrique chez un important fournisseur de ... SGBDR (le projet qu'on donne au vieil expert avant qu'il parte en retraite)

Le modèle de ma base de données propriétaire est rodé (depuis 21 ans). Elle était à base d'objets, ce que certaines SGBDR savent traiter, mais pas MySQL. Je n'ai pas connaissance du reste que ces extensions soient effectivement utilisées, les deux mondes étant trop distants pour que leur utilisation se généralise.

Ma question concernait le façon pratique dont on utilise ces ... (comme vous dites) de SGBDR surtout le langage SQL, extension du COBOL des années 80.

Les réponses qui ont été apportées à ma question, sans doute fort mal posée, m'ont conduit à essayer de retrouver des données diverses par une seule requête ce qui est une aberration, mais quand on arrive d'un autre monde on ne sait pas très bien quels sont les us et coutumes.
Je me suis rendu compte au bout de quelques essais de la stupidité de cette approche et je suis revenu à un design plus respectueux du bon sens, à savoir une requête par type "d'objet" (pardon pour le gros mot) et tout est rentré dans le rang.

A+