PHP|Débutant :: Forums

Bonjour,

Voici mes premiers conseils.
1) N'utilise jamais comme nom de champ un nom de fonction/d'opérateur MySQL (ex: le champ date de la table journees).
2) Crée ta logique de structure entièrement et suis là à la lettre dans ta structure. Pourquoi? parceque tu t'es perdu en chemin (tu n'as pas fait exactement ce que tu as dit bien que ce que tu as dit soit incomplet pour réaliser une structure complète solide), et du coup tu as crée de la redondance d'information dans certaines tables qui ne devraient pas exister. Donc du coup tu n'exploites pas ta structure à 100%.
3) Normalement tu dois avoir deux types de "structures" dans ton projet. Une structure construite pour gérer l'objet de ton projet (equipes,divisions,etc...) et une structure évènementielle (les championnats, tes matchs, les tableaux de rencontres, les feuilles de match de chaque équipe (je dis ça, je dis rien) et éventuellements quelques stats ou tout autre info sur l'évènementiel). A partir de là, tu te rends bien compte par exemple, que l'info division n'est pas qualifiante pour un championat mais pour une équipe tout comme son pays, ce qui qualifie le championat c'est son type : Champion's ligue, mondial, europe, national, etc...

Voila.

Dernière modification par Jc (31-07-2010 20:58:44)

Bonsoir,

Je te laisse re_réfléchir sur le 3, car il faut éviter le piège qui consiste à rajouter innoportunément des champs dans des tables pour en simplifier les requêtes, et confondre les jointures de structure avec la structure elle-même (voir la note en bas de page). Cependant, si tu es sûr de toi, il te suffit de faire comme suis concernant la partie divisions.

Equipes
...
id_division (avec index à doublons)
...

Championnats
clé primaire sur (id + id_division (avec index doublons) + id_saison (avec index doublons)), mais je pense que c'est ce que tu as fait

---------------------------------------------

Note
Concernant ma remarque sur les championnats, pour la reprendre et la développer et bien que je n'aime pas le foot, si on prend par exemple une équipe de division 2 sur le championnat de type national, même si dans le language courant, on parle d'un championnat de division 2 ca reste un championnat national pour une équipe de division 2. Par conséquent comme une équipe de division 2 ne peut faire un championnat de 1ere division, le championnat de l'équipe concernée ne peut être que de division 2. On obtient l'information de division via les contraintes de référence sur ta structure db, au sein de la table Equipes donc et non via la table championnat.
Pourquoi j'ai dit que la division est qualifiante pour l'équipe? Si l'info id_division est absente de la table équipe, toutes les équipes deviennent orphelines vis-à-vis des championnats, et structurellement, n'importe quel equipe peut participer à n'importe quel championnat.

Bonne nuit^^.

Dernière modification par Jc (01-08-2010 00:31:24)

Bonjour,

Pour répondre à ta première question, tu as tout as fait raison de ton point de vue . Le seul hic c'est que le jour où tu désires inscrire une équipe dans un autre championnat autre que son championnat "officiel", tu peux mettre ta structure à la poubelle. Regarde aux états unis. Chaque Etat à son championnat. Dans ton système tu fait comment pour gérer une équipe en tournoi NBA vu que la NBA n'est pas "un tournoi de division"? Je te laisse réfléchir à la question.

Un index à doublons, désolé pour cet abus de language, mais c'est un index qui autorise les doublons et donc le contraire d'un index à valeur unique (comme une clé primaire par ex).

Pour répondre à ta problèmatique concernant ta feuille de match, tu as deux façons possible de procéder
1) La première est comme tu l'as proposé, de passer par une table de jonction. C'est la structure la plus ouverte possible donc la solution non limitante en terme d'évolution d'application.
- L'avantage: Requêtes relativement simples à mettre en place et très rapides si les contraintes de structures sont appliquées correctement aux clés primaires.
- L'inconvénient: Comme tu l'as justement fait remarquer, selon le contexte applicatif tu peux te retrouver rapidement avec des centaines de milliers d'enregistrements assez rapidement. Et donc avec une grosse base de données.

2)  La seconde est de passer par un champ de type SET. La puissance de calcul de MySQL se limite à 64 enregistrements, ce qui convient parfaitement à une feuille de match car tu n'as que 11 joueurs il me semble sur la feuille de match et 25 en tout dans l'équipe.
- Les avantages: Conserve l'ouverture de ta base de données à une extension ultérieure de ton applicatif à condition de la structurer en conséquence. Cela peut réduire d'une manière très conséquente la taille de ta base de données (voir 1).
- Les inconvénients: Si l'on peut appeler ca des inconvénients, cela complique et peut rallonger de manière conséquente tes requêtes (de la centaine à plusieurs milliers de lignes selon l'applicatif). Cela oblige souvent également à passer par la structure "CASE WHEN ... THEN ... ELSE ....END" dans tes requêtes.
Pour te donner une idée, dans l'un de mes projets de developpement de régie pub, j'ai une requête qui me calcule un coeff multiplicateur sur le coût de base d'un encart publicitaire pour une année donnée dans une gestion à l'heure concernant sa diffusion. La requête fait presque 10 000 lignes, est certes 100 fois plus lente qu'une requête classique, mais ce résultat reste à relativiser car sa vitesse d'éxécution se situe entre 3 et 4 dixièmes de seconde..

Si tu as besoin d'explication sur la structure et le fonctionnement de ce type de champ n'hésite pas à demander.

Bon dimanche.

Dernière modification par Jc (01-08-2010 14:21:12)

Bonjour,

Pour ta table de jonction, ce n'est pas un problème surtout que pour ton jeu tu ne devra gérer les championnats que par rapport à l'équipe que tu gères. Ca limite quand même la gestion, bien qu'il te faille prévoir la gestion de poule et de matchs éliminatoires.

Pour gérer ton équipe, si cela peut t'aider voici quels devraient être les éléments constitutifs primaires de ta table equipes selon moi. id (clé primaire),nom,ville,type_sport_id (basket,foot, etc...), genre (masculine/féminine), catégorie_id (poussin,minimes,vétérans,etc...), pays_id, division_id, rang_mondial. En effet tous ces éléments identifient de manière unique une équipe.

Ps: J'ai oublié dans ta table équipe le champ logo dans lequel tu places le lien vers ton fichier / ou que tu inclues dans la base de données (au choix).

Dernière modification par Jc (01-08-2010 16:57:36)