12-02-2010, 09:28 AM
Merci beaucoup pour vos réponses.
Du coup, vous me faites douter sur quelque chose d'autre.... Comme on dit, une réponse amène une nouvelle question.
Pour la table des évènements, j'avais prévu ce genre de structure.
ET ma question était de savoir si
1/c'était judicieux ou s'il serait mieux de passer par une structure en relation n:m avec une table de liaison (eventId+playerId sans champ custom), sachant qu'un évènement ne pourra jamais concerner plus de deux joueurs, et que la majorité des évènements ne concerne qu'un seul joueur (dans ce cas player2=0)
et 2/si je conserve cette structure, laquelle des deux requêtes suivantes serait la meilleure pour récupérer les évènements concernant le joueur id=7 :
a. select * from Events where player1=7 or player2=7
b. select * from Events where player1=7 union select * from Events where player2=7
Note : Si je mets des index sur player1 et player2, la première requête ne semble pas vouloir les prendre en compte.... mais les unions c'est mal
Du coup, vous me faites douter sur quelque chose d'autre.... Comme on dit, une réponse amène une nouvelle question.
Pour la table des évènements, j'avais prévu ce genre de structure.
Code :
create table Events (
id int unsigned auto_increment,
type enum(....),
player1 int,
player2 int,
-- ....
data text, -- données sérialisées
primary key(id));
1/c'était judicieux ou s'il serait mieux de passer par une structure en relation n:m avec une table de liaison (eventId+playerId sans champ custom), sachant qu'un évènement ne pourra jamais concerner plus de deux joueurs, et que la majorité des évènements ne concerne qu'un seul joueur (dans ce cas player2=0)
et 2/si je conserve cette structure, laquelle des deux requêtes suivantes serait la meilleure pour récupérer les évènements concernant le joueur id=7 :
a. select * from Events where player1=7 or player2=7
b. select * from Events where player1=7 union select * from Events where player2=7
Note : Si je mets des index sur player1 et player2, la première requête ne semble pas vouloir les prendre en compte.... mais les unions c'est mal
html, javascript, blagues, midi, etc. => http://quentinc.net/