Discussion :

[GrandDeb]

Bonjour,

Je me suis mis à MySQL il y a 2 mois seulement, je n'ai pas encore assez de recul pour aller vers les bonnes solutions.

Mon problème est le suivant :

J'ai une table Classement contenant 1 colonne Joueur et 10 colonnes A,B,C,... contenant des scores.
Je voudrais faire ensuite 2 opérations, dans l'ordre indiqué, pour mieux comprendre les enchainements (j'apprends !):
1) Afficher un tableau à 2 colonnes, la première contenant Joueur et la 2eme contenant la somme des 5 meilleurs scores (sur 10) de la ligne (c.à.d. d'un joueur).
2) Ensuite, je voudrais faire le même travail mais rajouter une colonne donnant le rang calculé à partir de la somme des 5 meilleurs scores, sans départager les ex aequos, avec affichage par rang

Je sais le faire par code PHP, mais je voudrais le faire par des requêtes.
Si au moins je pouvais avoir une piste pour débuter ...
Si c'est impossible par requête, dites-le moi aussi, ça m'évitera de chercher quelque chose d'impossible


Merci

[Maljuna Kris]

Saluton,
J'ai deux nouvelles pour toi; une bonne et une mauvaise.
Je commence par la mauvaise : ta table n'est pas conforme aux normalisations de bases de données relationnelles qui s'appuient sur le modèle entités-relations.
Avant de te lancer avec MySQL, il te faut acquérir un minimum des notions qui régissent l'emploi des SGBDR.
La bonne nouvelle c'est qu'il y a tout sur ce site pour pallier ces manques et qu'une fois que ta base de données sera en formes normales les requêtes dont tu parles seront relativement simples à réaliser.

Commençons donc par le début, si tu veux bien ?
http://sqlpro.developpez.com/cours/modelisation/merise/
http://cyril-gruau.developpez.com/um.../ConceptionBD/

[GrandDeb]

Bonjour,

Merci pour ta réponse, mais je n'ai aucune réponse à mes interrogations.

Tu me dis : "ta table n'est pas conforme aux normalisations de bases de données relationnelles qui s'appuient sur le modèle entités-relations".

Alors là, je suis scotché ! J'ai UNE table avec un UN champ "Nom" et 10 champs "Scores". Il n'y a pas plus simple, il n'y a aucune autre donnée !
Alors ? En quoi cette table n'est-elle pas conforme ?

J'ai dit que j'avais résolu ma question en code PHP, mais ce n'est pas "immédiat", et la solution par requêtes n'est pas forcément simple, peut-être est-elle impossible à résoudre. Moi je ne le sais pas (s'il n'y a pas de solution par requête), je n'ai pas l'expérience, toi tu dois avoir une idée, mais si tu ne sais pas, autant le dire au lieu de me renvoyer à la documentation.

Je repose ma question : Est-ce possible, oui ou non, de répondre à mon pb par requêtes ? Réponses : "oui", "non", "je ne sais pas, faut réfléchir".
Et si oui, vers quoi chercher (je ne demande pas une solution toute faite).

Je voudrais préciser aussi que j'ai dans mon ordinateur en gros un millier de pages de documentation, que je lis assez vite, mais tout le monde sait que pour assimiler tout ça, il faut du temps, et en ce qui me concerne, beaucoup d'exemples.

Merci pour toute autre contribution pour m'éclairer

[Maljuna Kris]

Ne te fâches pas, tu dis que tu t'es mis à MySQL depuis 2 mois, je pense que tu ne peux pas faire l'économie d'un minimum de connaissances fondamentales afférentes aux SGBDR.
Je t'illustre mon propos, dans ta table, les 10 colonnes qui contiennent les scores sont de même type et contiennent, sémantiquement, la même information.
Nous avons donc par ce biais dans la table une donnée qui n'est plus scalaire, mais tabulaire. Ces scores, pour un joueur, ne devrait pas être en colonnes mais en lignes.
Une ligne pour le score A, une ligne pour le score B etc ...
Mais expliquer la modélisation des bases de données ne se fait pas sur un coin de post en deux phrases, je t'ai donné 2 liens vers d'excellents tutoriels qui expliquent en long et en large toutes ces problématiques.
Je peux même t'en fournir un autre :
http://fr.wikipedia.org/wiki/Merise_(informatique)
maintenant si tu ne veux pas les lire...

[GrandDeb]

Bonjour,

Je ne me fâche pas, je pose des questions et je n'ai toujours aucune réponse sur la faisabilité.
Je préfèrerais que tu me dises que ce que je cherche est impossible par requêtes, ou que peut-être dans 6 mois, j'y arriverai si je m'accroche, mais là... rien. Va voir la doc...
Je ne comprends pas ce que tu me dis sur cette histoire de table avec le nom et les scores situés verticalement : quand je regarde une table SQL, je vois bien que les champs sont disposés en colonnes, même si dans les schémas théoriques, on fait un carré avec le nom de la table au-dessus, et que les différents champs sont sur des lignes. Et certaines fonctions comme MAX, AVG, MIN, ne se font que sur les données d'un seul champ, c.à.d. des colonnes, alors que je veux faire des calculs sur des données d'une ligne dans des champs différents.

La seule conclusion logique que je tire de ta remarque, c'est que j'ai peut-être intérêt à faire une table par joueur pour résoudre mon problème. Je vais étudier la question.

Quant à la méthode Merise, OK, mais il n'y a rien de concret, j'ai bien lu ce qui suit :

Le MLT modèle logique des traitements
Le MLT, appelé aussi MOT pour « modèle organisationnel des traitements », décrit avec précision l’organisation à mettre en place pour réaliser une ou, le cas échéant, plusieurs opérations figurant dans le MCT. Il répond aux questions suivantes : qui ? quoi ? où ? quand ? comment ? À un MCT correspondent donc généralement plusieurs MLT.

Les notions introduites à ce niveau sont : le poste de travail, la phase, la tâche et la procédure.

Le poste de travail
Le poste de travail décrit la localisation, les responsabilités, et les ressources nécessaires pour chaque profil d’utilisateur du système.
Par exemple, on peut identifier les profils suivants : client-web, responsable commercial, responsable des stocks, etc.
La phase
La phase est un ensemble d’actions (cf. la notion d’opération pour le MCT) réalisées sur un même poste de travail.
La phase peut être :
soit manuelle : par exemple, la confection d'un colis ;
soit automatisée et interactive : par exemple, la saisie d’un formulaire client ;
soit automatisée et planifiée (on parle aussi de batch) : par exemple, la production et l'envoi quotidiens de tableaux de bord dans les boites aux lettres électroniques.
La tâche
La tâche est une description détaillée d’une phase automatisée interactive.
Par exemple, elle correspond à la spécification de l’interface et du dialogue humain-machine, à la localisation et la nature des contrôles à effectuer, etc.
La procédure
La procédure est un regroupement de phases. Elle équivaut sur le plan organisationnel aux notions d’opérations et d’actions conceptuelles. La différence est que l'on considère ici ces dernières comme se déroulant sur une période de temps homogène.
Des procédures d’origines non conceptuelles peuvent être ajoutées du fait des choix d’organisation effectués.
Par exemple, on peut citer les procédures d’échanges d’informations liées à l’externalisation de certaines activités, la prise en compte des questions de sécurité en cas de choix de solution Web, etc.

Niveau physique [modifier]
Les réponses apportées à ce dernier niveau permettent d'établir la manière concrète dont le système sera mis en place.


le Modèle Physique des Données (ou MPD ou MPhD) permet de préciser les systèmes de stockage employés (implémentation du MLD dans le SGBD retenu)
le Modèle Opérationnel des Traitements (ou MOT ou MOpT) permet de spécifier les fonctions telles qu'elles seront ensuite réalisées par le programmeur.

Les différentes phases d'un projet MERISE [modifier]
Un projet élaboré selon la méthode MERISE est composé de différentes phases :

L'étude préalable : elle décrit les besoins et les attentes des utilisateurs, les traitements (processus métier) pour la procédure représentative (modèle conceptuel des traitements, modèle logique des traitements, ébauche de modèle physique des données), et les principales données (modèle conceptuel des données, modèle logique des données, ébauche de modèle physique externe des traitements),
L'étude détaillée : elle décrit les besoins, traitements, et données de façon plus détaillée pour chaque procédure fonctionnelle. L'étude détaillée se décompose elle-même en :
Spécifications fonctionnelles générales (Tableau des opérations par processus, TOP), écrites par la maîtrise d'ouvrage,
Spécifications fonctionnelles détaillées, écrites par la maîtrise d'œuvre,
L'étude technique : elle décrit les moyens techniques nécessaires à la réalisation de l'application (environnement technique, SGBD, langages informatiques, consignes de développement,...).

Merci quand même, je peux résoudre mon problème par PHP (variables, boucles et conditions) et par Excel (avec la fonction RANG). Je voulais simplement savoir si par requêtes on peut y arriver.
Et je ne le sais toujours pas.

[Maljuna Kris]

Quelle consternante mauvaise foi !
Je t'ai dit que ta table ne permettait pas en l'état d'obtenir ce que tu cherches.
Je t'ai dit pourquoi.
Je t'ai dit comment y remédier.
Je t'ai dit

une fois que ta base de données sera en formes normales les requêtes dont tu parles seront relativement simples à réaliser.

Je t'ai fourni les liens vers tout ce qu'il semble manquer à tes connaissances sur les SGBDR.
Et tu as le culot de faire l'enfant gâté en prétendant

et je n'ai toujours aucune réponse sur la faisabilité.

Tu ne mérites vraiment pas qu'on se donne davantage de mal pour t'aider.

[GrandDeb]

Tu me dis :"Je t'ai dit comment y remédier."---> traduction : Va voir la doc.
Donc RV dans 1 an, peut-être.

Merci quand même

[Maljuna Kris]

Tu es vraiment lourd !

Ces scores, pour un joueur, ne devrait pas être en colonnes mais en lignes.
Une ligne pour le score A, une ligne pour le score B etc ...

Tu appelles ça RTFM ?
Va te cacher !

[Sivrît]

Alors là, je suis scotché ! J'ai UNE table avec un UN champ "Nom" et 10 champs "Scores". Il n'y a pas plus simple, il n'y a aucune autre donnée !
Alors ? En quoi cette table n'est-elle pas conforme ?

Elle n'est pas sous une forme normale. En gros, en termes de modélisation, à chaque fois que l'on entend l'expression "N colonnes pour telle chose" (ici dans sa variante "10 colonnes A,B,C,... contenant des scores"), on se dit que c'est louche. Si c'est N fois la même chose (même nature, ie un score), ce devrait être la même colonne. Des colonnes différentes sont supposées contenir des information différentes.

Je ne comprends pas ce que tu me dis sur cette histoire de table avec le nom et les scores situés verticalement : quand je regarde une table SQL, je vois bien que les champs sont disposés en colonnes, même si dans les schémas théoriques, on fait un carré avec le nom de la table au-dessus, et que les différents champs sont sur des lignes. Et certaines fonctions comme MAX, AVG, MIN, ne se font que sur les données d'un seul champ, c.à.d. des colonnes, alors que je veux faire des calculs sur des données d'une ligne dans des champs différents.

De même, se retrouver à devoir réaliser une opération sur un ensemble de colonnes doit généralement mener à s'interroger sur sa modélisation. Le SQL est fait pour manipuler des ensembles d'enregistrements (lignes), pas des ensembles de colonnes. Le principal problème de ce point de vue étant que l'on doit citer nommément les colonnes dans les requêtes.

Il serait malgré tout possible de faire ce que tu souhaites en SQL avec cette modélisation. Presque tout est possible avec du SQL. Que ce soit souhaitable c'est autre chose : Si ça suppose une requête de 3 pages qui prend 2 jours à tourner en remplaçant 10 lignes de PHP, le choix est vite vu
Puisque le nombre de colonnes de score est connu, ça devrait se faire avec un nombre indécent de IF, ou alors avec des UNION ALL, mais je pense qu'il vaut mieux s'épargner ça.


Ici, il faudrait vraisemblablement une table "scores" avec trois colonnes : identifiant du joueur, identifiant du type de score (ou question, ou match, ou épreuve, ou quoi que ce soit), et enfin le score correspondant. Les scores pourraient ainsi être manipulés via MIN, MAX, AVG, etc.

Reste que, pour être franc, les manipulations sur les N premiers éléments pour un critère donné sont malaisées en SQL. Et l'attribution de numéros / classements restent plus efficaces à faire du côté de l'application cliente. Du coup, y aller avec du PHP n'est peut-être pas si mal.

[GrandDeb]

Merci pour ces éclaircissements : malgré ce que j'ai lu dans les docs, j'ai forcément des représentations mentales fausses sur les bases de données, surtout que j'ai plus l'habitude de travailler sur tableur. Après quelques essais sur des exemples précis avec les tatonnements et les échecs inévitables qui vont avec, ça ira mieux.

Je me posais aussi la question de savoir si ce pb était entièrement résolvable par requêtes, il me semble que j'ai compris qu'un compromis tables/code PHP peut-être parfois avantageux, avec les tables pour stocker les données et le code pour traiter des opérations qui s'écartent des opérations de base (addition...).

Quand j'aurai un moment, je me remettrai à chercher une solution par requêtes.

Merci encore.