Discussion :

[Snipy]

Bonjour à tous,

J'ai actuellement une table matchs,

matchs
id
champ_id (l'id du championnat)
equipe_dom(domicile)
equipe_ext(exterieur)
score_dom
score_ext
...

J'aimerais pouvoir afficher le classement de chaque championnat.

Ma question : devrais je calculer le classement a chaque fois en récupérant chaque match de chaque championnat et en fonction des scores voir qui a chaque fois a gagné et lui donné les points de la victoire ou de la défaite,

ou alors, faire une table classements

tel que :

classements
id
champ_id (id du championnat)
equipe_id
points (points au championnat)

Et dans ce cas la il me suffirait de faire

Code :

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

SELECT equipe_id FROM classements WHERE champ_id = monchampionnat ORDER BY points

MAIS PAR CONTRE APRES chaque match je devrais faire 2 update pour mettre à jour les points des 2 équipes dans leur championnat.

Merci d'avance de me partager votre experience

[RunCodePhp]

Salut

MAIS PAR CONTRE APRES chaque match je devrais faire 2 update pour mettre à jour les points des 2 équipes dans leur championnat.

Par à ça, et si on se tient à la strict norme SQL (ou conception Bdd), il ne faut pas de table classements, mais calculer.
En faite, il est dit qu'il ne faut pas stocker des données qui seraient dépendantes des unes des autres, comme ton exemple qui serait l'exemple type.
En gros, on modifie à droite, du coup celle de gauche devient absurde ou incohérente, donc c'est l'applicatif qui fait qu'une mise à jour se fera pour conserver la cohérence.

Ici, on dit que ces données sont redondantes, ou plus simplement, c'est de la duplication de données (même si elles sont au finales calculées).

Ceci dit, tout ça c'est théorique, mais dans la pratique, faut voir.
Une des raisons qui pousse à transgresser les bonnes règles de conception c'est le coté performance, ou plutôt chute des performances à cause d'un calcul/traitement qui serait trop lourd.
En bref, c'est de l'optimisation.


Faut voir si cela vaut le coup de ton coté, et le coté risque d'incohérence qu'il pourrait avoir en cas de bug par exemple.
En gros, est ce que ces calculs ont un réels impacte sur les performances ?
Est ce que SQL est suffisamment bien exploité bien pour les calculs ?
(bien souvent c'est Php qui se tape le gros du boulot, alors que SQL peu le faire aussi, ou en partie).


Comme ça, au feeling bien sûr, je dirais que tant que l'année n'est pas terminée, faire les calculs serait suffisant, ou plus sûr.
Par contre, une fois l'année terminée, donc tous les match effectués, on peu donc dire que tout est figé, du définitif.
Du coup, à quoi bon sans cesse calculer des données qui ne se modifieront jamais.
Ici, créer une table classement pour stocker annee - 1 (donc l'historique) serait tout à fait adaptée.
Pur exemple de cas.

[kileak]

Salut,

j'adore ta question car elle me replonge en 2004 quand j'ai monté avec un pote le modeste prono-sport com

Je m'étais posé les mêmes questions avec le même genre de réflexion de principe que te détaille RunCodePhp.

Au final nous avons opté pour 2 tables pour des raisons de clarté et de performance. Pas envie de faire recalculer le classement après x des 380 matchs de L1 à chaque visite.
Avoir le classement après une journée te permet de faire des stats facilement (oui tu aurais pu les calculer aussi mais on en revient au perf).

De toutes les façons, quand fais-tu les màj ?
Après chaque journée de championnat ? Ok, donc tu peux faire une màj des matchs puis des classements.

Autre finesse, il arrive que le classement se joue sur des détails un peu tordus (fairplay, goal average particulier...) va calculer tout ça
Dons j'ai aussi fait une page me permettant de modifier le classement à la main dans ces cas où le calcul n'est plus suffisant.
Donc, perso, une bonne table classement archivable (pour stats) ou pas et c'est parti.

Après, c'est sûr nous ne sommes pas dans du "3FN" (de mémoire) mais tant pis.

Par curiosité, c'est quoi ton site ? (tu peux mettre ton joker, je comprendrai )

En espérant t'avoir aidé,
à+

[divot]

Bonjour,

Je ne suis pas un spécialiste de mysql et il se peut qu'il y ait dans ma réponse des erreurs de syntaxe.

A priori, je répondrais à ton problème en créant 4 tables :

• une table équipe avec un id, son nom, etc

• une table match avec un id, une date, etc

• une table score_exterieur avec une clé externe vers la table équipe et une clé externe avec la table match, un nombre de points, et le nombre de buts (panier, ...)

• une table score_recevant avec les mêmes données

puis j'écrirais la requête suivante (mais je ne l'ai pas vérifié)

SELECT nom_equipe,

(SUM(score_recevant.point)+SUM(score_exterieur.point)) AS sum_points,

(SUM(score_recevant.but)+SUM(score_exterieur.but)) AS sum_but

FROM equipe, match, score_recevant, score_exterieur
WHERE equipe.id_equipe=score_exterieur.id_equipe AND equipe.id_equipe=score_recevant.id_equipe
ORDER BY sum_point, sum_but

Cela nécessite évidement de calculer les points au moment de la saisie du match mais la fonction peut être automatisée avec une table complémentaire qui donne les points en fonction du type de sport, ...
On peut aussi gérer la notion d'année.

En procédant ainsi tu profites au maximum des potentialités de la base de données en ayant toujours des calculs temps réels. Je crois en outre que le résultat de la requête risque de se mettre en cache si elle est exécutée plusieurs fois et donc améliorer le temps de réponse.

[kileak]

salut divot,

je ne sais pas si mysql dans sa version MyIsam (pas InnoDB) sait gérer le cache. Je n'ai jamais creusé mais ça serait bien.

Par contre je ne vois pas l'intérêt d'avoir 2 tables pour les données d'un match dont font parti le résultat et donc les buts (points) domicile et extérieur.
Si je prends mon cas personnel, on n'a qu'une seule table match avec toutes les infos nécessaire et lors du calcul on somme les buts domicile/extérieur via une jointure match as match_dom et match as match_ext.
Mais au final on ne gère qu'une table ce qui aussi l'avantage, qd on veut afficher
la liste des matchs et leurs résultats, de ne faire qu'un select sans jointure sur une journée d'une compétition donnée.

à+