OK. Sujet clos !

Note bien que je ne suis pas foncièrement opposé au cross-posting, parfois on ne trouve pas de réponse sur un forum, il est normal de vouloir trouver en posant la question ailleurs, mais en règle générale, on l'évite d'autant plus que le forum réagit rapidement. Tu as posé ta question tard hier soir, la réponse est arrivée ce matin, ce n'est quand même pas si terrible comme attente.

Je vais dire en outre : on a un forum vivant ici, et on souhaite le garder vivant. En appliquant (et en faisant appliquer) les règles de la [i]Netiquette[/i] partout, on pourra avoir des communautés de dévelpoppement efficaces. Comprends bien qu'il est frustrant quand on répond à un message de toruver exactement la même question sur un autre forum: il y a forcément quelqu'un qui répond pour rien sur un des deux (ou davantage, ça s'est déjà vu)

Bon code.

P.S.: J'ai vu la note de Laurent Denis sur mon post, je lui ai envoyé un message privé, je ne souhaite pas avoir de conflit avec qui que ce soit et il n'y en aura pas non plus. À l'occasion, lis donc les règles du forum de PHPFrance, l'article 1 est très explicite sur le sujet.

Oui un modo y a fait un commentaire.

Je te répète qui je ne voulais pas froissé, je n'étais pas au courant de cette règle de cross-posting. Je le ferai plus promis :wink:

et merci de ton aide.

Pas de quoi, tu n'oublieras pas non plus d,aller mettre [Résolu] dans le titre de [url=http://forum.alsacreations.com/topic.php?fid=20&tid=5955]ton message posté[/url] sur le Forum de alsacreation. Et tu y liras aussi maréponse concernant le cross-posting !

Merci Cyrano.

Ce serait assez ça à un détail près : les clés étrangères ne doivent surtout pas être en auto_increment sinon tu ne pourras pas avoir plus d'une réservation par match: donc
[code]TABLE resa
id_resa INT(11) AUTO INCREMENT;
id_mb INT(11) not null;
id_match INT(11) not null;
qte DECIMAL(2) not null;
PRIMARY KEY (id_resa)[/code]
J'ajouterais que pour optimiser, tu pourrais même indexer les clés étrangère pour accélérer notablement les recherches.

Par contre, j'ai un doute sur le champ "qte" : si c'est le nombre de personne correpondant à une réservation, le type de champ n'est pas approprié, DECIMAL correspondant à un champ de type "double" ou "float". Il serait plus judicieux de choisir un type de champ TINYINT , ce qui met le maximum à 255 personnes, ça commence à faire pas mal de monde pour une réservation, au pire si il peut arriver qu'il y ait plus de monde, mets le en MEDIUMINT ce qui monte à plus de 65000 personnes possibles pour une réservation.

[b]TABLE membre
id_mb INT(11) AUTO INCREMENT not null;
prenom VARCHAR(20) not null;
nom VARCHAR(20) not null;
naissance DATE not null;
etc ....
PRIMARY KEY (id_mb)[/b]

[b]TABLE match
id_match INT(11) AUTO INCREMENT not null;
match VARCHAR(20) not null;
date DATE not null;
prix FLOAT(5) not null;
etc ....
PRIMARY KEY (id_match)[/b]

Voilà mes 2 tb principales qui à l'écran m'affiche une liste d'abonnés ou une liste de matchs disponibles.

Maintenant je voudrai créer une 3ème table RESERVATION qui me permettrait de lier des abonnés avec un match qu'ils auraient réservé.
A chaque nouvelle réservation, je devrai donc pouvoir associer un membre à un match de sorte que je puisse afficher toutes les résa. soit pour un membre, soit pour un match.

J'avais donc pensé faire ma table de cette façon :

[b]TABLE resa
id_resa INT(11) AUTO INCREMENT;
id_mb INT(11) AUTO INCREMENT not null;
id_match INT(11) AUTO INCREMENT not null;
qte DECIMAL(2) not null;
PRIMARY KEY (id_resa)[/b]

Mets-nous la structure de tes tables (noms et types de champs) en expliquant aussi clairement et simplement ce que tu voudrais faire. J'ai bien une vague idée, mais ça ne me tente pas de répondre à coté du sujet...

Salut à tous,

Voilà, je bloque dans la progression d'un projet où j'ai une table MEMBRE et une table MATCH.

Je voudrai maintenant faire une table RESERVATION, qui utiliserait l'id de la table MEMBRE (id_membre) et l'id de la table MATCH (id_match) afin d'obtenir une gestion des réservations qui pourront s'afficher soit en sélectionnant un match soit un membre.

Par contre je bloque dans la façon d'amener cela dans ma requête SQL sur la table RESERVATION.

Quelqu'un pourrait-il m'aider SVP ? Merci.