[quote="jpsartre"]J'ai mis le temps mais je crois que j'ai compris, le mieux serait donc de mettre le champ (vrai/faux) dans le panier et enlever le champs nombre de réservations dans la table événements. Comme ça je pourrais en listant les événements dans la table panier selon vrai ou faux les compter.
par exemple j'aurais ça dans ma table panier (id, pseudo, ref, reservation)
A savoir que c'est l'administrateur qui confirme quand il reçoit le paiement.
[/quote]

Toutafé ! :)

Lorsque l'administrateur confirme (ou infirme) une réservation, c'est la table panier qui sera mise à jour. Et effectivement il te suffit de compter les enregistrements pour un événement donné pour savoir combien il y en a de confirmé :
[code]SELECT COUNT(*) FROM panier WHERE ref='xxx' AND confirm = 1 ; (ou 0 le cas échéant pour les non confirmés)[/code]

Normalement quand tu as une relation de type N pour N (un utilisateur peut être rattaché à 0 ou n événement, un événement peut être lié à 0 ou n utilisateurs) on utilise comme tu l'as fait une table intermédiaire. La clé de cette table est constituée des deux clés étrangères. Et tu peux ensuite compléter avec des infos concernant la liaison (ici ta confirmation)

Pour ta table panier, le mieux serait donc de la constituer comme ceci :

[code]CREATE TABLE panier (
id_abonne int(11) NOT NULL,
id_evenement int(11) NOT NULL,
confirm tinyint(4),
PRIMARY KEY (id_abonne, id_evenement)
);[/code]

Ta clé unique est composé des deux identifiants (un utilisateur peut être lié à N événements, mais il ne peut être lié au plus qu'une fois à chacun).
L'avantage est que tu es sur que tes champs id_utilisateur et id_evenement sont uniques puisque ce sont les clés de tes deux autres tables, contrairement à pseudo ou ref (même s'ils sont je suppose géré de manière applicative pour être unique) pourraient comporter des doubles...

Si tu as besoin de ces valeurs, tu peux facilement à partir de la clé d'un enregistrement (id_abonne, id_evenement) aller rechercher dans les tables abonne ou evenement, le pseudo ou la référence qui correspondent :) Tu les gardes ainsi une seule fois en base, et si éventuellement leur valeur change, ton lien reste correct :)

Bon maintenant, ce que tu as fait fonctionne, donc pas la peine de tout casser et refaire hein ;) c'est juste pour te donner la méthode communément utilisé et les avantages qu'elle apporte :)

Merci pour tes conseils,

[quote]Par contre si je peux me permettre quelques remarques sur la structure de ta base, personnellement je n'aurais pas mis le champ pseudo dans la table pannier. Je suppose que celui-ci est déjà présent dans la table abonnés, et donc l'info est redondante, d'autant que tu utilises déjà une clé pour lier ces deux tables. (tant que possible, les données ne doivent se situer qu'à un seul endroit dans une base) [/quote]

Je comprends la pertinence de ta remarque mais il est vrai que j'ai du mal avec ce genre d'optimisation, c'est pas très clair pour moi. Mais je vais m'y pencher car c'est logique de faire comme tu dis.

[quote]Autre suggestion, plutot que de comptabiliser les événement confirmés dans la table événement, j'ajouterais un champ "confirmé" (vrai ou faux) dans la table pannier. Tu sais ainsi qui à confirmé quel événement, tu peux facilement compter ceux qui sont confirmés et ceux qui ne le sont pas, et une fois encore, si quelqu'un confirme, tu n'as qu'un seul champ à modifier sans avoir à faire de calcul [/quote]

J'ai mis le temps mais je crois que j'ai compris, le mieux serait donc de mettre le champ (vrai/faux) dans le panier et enlever le champs nombre de réservations dans la table événements. Comme ça je pourrais en listant les événements dans la table panier selon vrai ou faux les compter.
par exemple j'aurais ça dans ma table panier (id, pseudo, ref, reservation)
A savoir que c'est l'administrateur qui confirme quand il reçoit le paiement.
Je mets mes tables pour être sûr.

[code]CREATE TABLE abonnes (
id int(11) NOT NULL auto_increment,
nom varchar(255) NOT NULL,
prenom varchar(255) NOT NULL,
dd date DEFAULT '0000-00-00' NOT NULL,
df date DEFAULT '0000-00-00' NOT NULL,
di date DEFAULT '0000-00-00' NOT NULL,
dn date DEFAULT '0000-00-00' NOT NULL,
tf varchar(255) NOT NULL,
tp varchar(255) NOT NULL,
mail varchar(255) NOT NULL,
type varchar(20) NOT NULL,
adresse text NOT NULL,
cp varchar(255) NOT NULL,
ville varchar(255) NOT NULL,
pseudo varchar(255) NOT NULL,
passw varchar(255) NOT NULL,
profil text NOT NULL,
PRIMARY KEY (id)
);[/code]

[code]CREATE TABLE evenements (
id int(11) NOT NULL auto_increment,
ref varchar(255) NOT NULL,
nom varchar(255) NOT NULL,
statut int(11) DEFAULT '0' NOT NULL,
dd date DEFAULT '0000-00-00' NOT NULL,
df date DEFAULT '0000-00-00' NOT NULL,
hd time DEFAULT '00:00:00' NOT NULL,
hf time DEFAULT '00:00:00' NOT NULL,
type varchar(20) NOT NULL,
commentaire text NOT NULL,
description text NOT NULL,
rdv varchar(255) NOT NULL,
prix varchar(255) NOT NULL,
maxi int(11) NOT NULL,
mini int(11) NOT NULL,
reserve int(11) NOT NULL,
PRIMARY KEY (id)
);[/code]

[code]CREATE TABLE panier (
id int(11) NOT NULL auto_increment,
ref varchar(255) NOT NULL,
pseudo varchar(255) NOT NULL,
PRIMARY KEY (id)
);[/code]

Merci

Pourquoi ne pas simplement compter le nombre d'enregistrements dans ta table panier pour un événement donné ? Tu aurais ainsi directement le nombre de réservations (confirmées et non confirmées) et puisque tu as déjà le nombre de réservations confirmées dans ta table événement, une simple différence te suffit :) (pis ca évite d'avoir un champ supplémentaire à mettre à jour en cas de modification d'une réservation)

Par contre si je peux me permettre quelques remarques sur la structure de ta base, personnellement je n'aurais pas mis le champ pseudo dans la table pannier. Je suppose que celui-ci est déjà présent dans la table abonnés, et donc l'info est redondante, d'autant que tu utilises déjà une clé pour lier ces deux tables. (tant que possible, les données ne doivent se situer qu'à un seul endroit dans une base)

Autre suggestion, plutot que de comptabiliser les événement confirmés dans la table événement, j'ajouterais un champ "confirmé" (vrai ou faux) dans la table pannier. Tu sais ainsi qui à confirmé quel événement, tu peux facilement compter ceux qui sont confirmés et ceux qui ne le sont pas, et une fois encore, si quelqu'un confirme, tu n'as qu'un seul champ à modifier sans avoir à faire de calcul :)

Bon après tu fais comme ça t'arrange hein ;)

Bonjour,
J'ai fait un système permettant aux abonnés de sélectionner et stocker dans une table des événements:
1 table abonnés
1 table événements
1 table panier (pour faire la liaison)
et ça marche;
J'aimerais compléter le système. Mais avant j'aimerais savoir si je suis sur la bonne voie.
J'aimerais que :
- à chaque fois qu'un abonné sélectionne un événement, le nombre de réservations s'incrémente.
- l'administrateur puisse valider les réservations payées.

Dans ma table événement j'ai un champ prévu pour le nombre total de réservations confirmées mais pas de champ pour les réservations non confirmées.

Dans matable de liaison panier, j'ai juste l'id de l'enregistrement, le pseudo de l'abonné, et la référence de l'événement.

Et je me demandais dans quelle table stocker les réservations non-confirmées d'une part, et d'autre part si ça tenait la route, et me permettrait de faire ce que je veux.

Merci,