Au sujet de la conception d'une base

[Roworll]

La 2e modélisation est plus adaptée je pense.

Il n'y a pas de mystères de toute manière. Pour avoir toutes les informations match/joueur/challenger sur une ligne, tu dois jointer deux fois la table players

Pour récupérer les informations, tu peux utiliser une structure de requête plus conventionelle

Code :

SELECT * FROM matchs
    INNER JOIN players AS opponent   ON (opponent.players.id = matchs.player_opponent)
    INNER JOIN players AS challenger ON (challenger.players.id = matchs.player_challenger)

Alternativement, si le moteur supporte, tu peux utiliser les requêtes imbriquées

Code :

SELECT
    *,
    (SELECT name FROM players WHERE player_id=matchs.player_opponent) as opponent_name,
    (SELECT name FROM players WHERE player_id=matchs.player_challenger) as challenger_name
FROM matchs

[Roworll]

Ca dépends de la manière dont tu envisage de faire évoluer ton projet.
Dans le cas ou les match sont toujours du 1vs1, l'enum n'est pas intéressant.

Il est en effet clairement établi que 1 Match est reliè à 2 joueurs
Pour chaque match, au lieu d'avoir une ligne du type
- Match - J1 - J2 -
tu vas te retrouver avec deux lignes
- Match - J - type -
- Match - J - type -
La table sera plus longue à parcourir et au final (un peu) plus grosse

Si au contraire tu envisages de faire des matches avec un format plus exotiques on se retrouve dans une relation 1 match - n joueurs

Dans ce cas, tu dois avoir une ligne par joueurs dans la table de liaison match/joueurs.
l'Enum fera alors la distinction pour savoir dans quelle équipe est placé le joueurs.
Pour ma part je préferai un simple flag de type Bit ou TinyInt en fonction du nombre d'équipes participant au match.

Avant de modéliser donc, tu dois avoir une vision claire de ce que tu veux obtenir et des éventuelles possibilités que tu veux intégrer.

Pour finir, on pout trouver des tonnes de design 'sexy' et/ou inventifs mais cela se fait souvent au prix d'une perte de performances ou de souplesse. D'expérience, je ne peux que te conseiller d'utiliser les design efficaces.

[Sephi-Chan]

Je pense au vu du thème qu'il y aura aussi des parties en double, donc qu'on est dans une relation finie : il peut y avoir soit 1v1, soit 2v2.

Donc je vois ça comme une table de relation dont les champs sont :

• id_partie ;
  
• id_joueur ;
  
• id_equipe ;
  

Sephi-Chan

[Roworll]

Je veux du efficace mais sexy :p

Je devrais remonter ça aux développeurs de ma boite.
Leur dernière exploit portait sur une modélisation hyper-sexy-de-la-mort-qui-tue d'une base de donnée.
Plusieurs mois d'analyse, de dev, de test internes et tous fiers d'eux, ils ont fait un gros lancement. Ca à pas mis 6 mois avant de montrer ses limites. Incapable de supporter la charge des utilisateurs, le modèle n'était en fait pas assez souple tout ça à cause de leur design "soigné et original" qui n'avait pour but que de flatter l'ego du chef de projet.

Résultat, un responsable mis à la porte, des 10aines de milliers d'euros foutus à la poubelle et des développeurs qui recommencent presque tout depuis le début.

A vouloir réinventer la poudre, on risque de tout se faire péter dans les doigts. autant s'appuyer sur les méthodes traditionnelles, elles ont fait leurs preuves.

Donc, je recommande chaudement d'utiliser le schéma classique avec une table de liaison match/joueur dans l'optique de ce que propose Sephi-chan et qui correspond à ce que je disais plus haut (1-n)

[Roworll]

Hop, deux petits liens expliquant la méthode d'analyse MERISE
Sam-Mag
Developpez.com

Si tu as des doutes sur la structure de ta base de données essayes d'appliquer cette méthodologie pour valider ton modèle.
Il en existe d'autres mais MERISE est très largement éprouvé et ce dans un grand nombre de cas.

[Sephi-Chan]

SELECT * FROM matchs
INNER JOIN players AS opponent ON (opponent.players.id = matchs.player_opponent)
INNER JOIN players AS challenger ON (challenger.players.id = matchs.player_challenger)

Quelques questions (pas de critiques cachées) me viennent à l'esprit :

• Pourquoi mettre des parenthèse à la clause ON des jointures ?
  
• Pourquoi tu n'utilises pas d'alias de tables ?
  
• Tu ne sélectionnes des informations que dans la table matchs ?
  

Peut-être cette requête n'est qu'un exemple, et dans ce cas mes questions n'ont pas raison d'être.


Sephi-Chan

[Roworll]

Oué enfin ça ne m'apprend rien ça

Ca pose juste les bases de la modélisation et explique comment la transformer en un schéma de bases de données adéquats.

Vu les questions que tu te poses, j'ai comme l'impression que ton schéma n'est pas encore très clair ce qui laisse supposer que l'analyse et/ou la modélisation sont passés à la trappe.

[Sephi-Chan]

Oxman ! Me dit pas que tu as fais ça !?