c'est un peu fouillis ton affaire
pour le second formulaire si tu doit l'afficher au clic (bouton, case à cocher ou autre) il faut effectivement utiliser javascript. N'importe quel framework JS (comme jquery ou extjs) devrait t'y aider facilement.
ensuite pour expliquer plus facilement ce que j'ai voulu dire voici un exemple concret du modèle proposé (merise)
le MCD (modèle conceptuel de données)
Le MDP (modèle physie que données) correspondant
ceci se traduit par ce code SQL
[mysql]CREATE TABLE user(
userid int (11) Auto_increment NOT NULL ,
nom Varchar (25) ,
prenom Varchar (25) ,
PRIMARY KEY (userid )
)ENGINE=InnoDB;
CREATE TABLE projet(
projectid int (11) Auto_increment NOT NULL ,
nom Varchar (25) ,
description Varchar (255) ,
PRIMARY KEY (projectid )
)ENGINE=InnoDB;
CREATE TABLE groupe(
groupId int (11) Auto_increment NOT NULL ,
groupName Varchar (25) ,
PRIMARY KEY (groupId )
)ENGINE=InnoDB;
CREATE TABLE userGroup(
dtGroup Date ,
userid_user Int NOT NULL ,
groupId_groupe Int NOT NULL ,
projectid_projet Int NOT NULL ,
PRIMARY KEY (userid_user ,groupId_groupe ,projectid_projet )
)ENGINE=InnoDB;
ALTER TABLE userGroup ADD CONSTRAINT FK_userGroup_userid_user FOREIGN KEY (userid_user) REFERENCES user(userid);
ALTER TABLE userGroup ADD CONSTRAINT FK_userGroup_groupId_groupe FOREIGN KEY (groupId_groupe) REFERENCES groupe(groupId);
ALTER TABLE userGroup ADD CONSTRAINT FK_userGroup_projectid_projet FOREIGN KEY (projectid_projet) REFERENCES projet(projectid);[/mysql]
les tables user et projet tu les comprend facilement
la table groupe (ou pour ne pas limiter la chose à binôme) contient un id et nom. elle permet aussi de regrouper les "user" (élève dans ton cas).
la table userGroup fait la liaison entre tous cela.
La clef primaire c'est une clef sur trois colonne.
Cela permet d'éviter d'avoir un "user" qui sont deux fois dans le même groupe pour le même projet (c'est gérer par les contraintes d'intégrité de la base).
donc lorsque que créer ton binôme tu ajoute une ligne dans groupe (et tu récupère l'id du groupe), puis deux lignes dans usergroup (une par élève) avec l'id groupe que tu viens de créer et et les id des utilisateurs et du projet que tu as obtenu grasse au formulaire
LA chose peux te sembler tordue ou complexe, mais c'est quelque chose de solide, évolutif et flexible (même si le nom du groupe reste une contrainte).
si tu veux ta passer du nom du groupe il est tous à fait possible de supprimer la table groupe et d'ajouter dans usergroup une colonne pour le second "user" mais la du coup le système n'est pas évolutif et tu ne peux pas modifier le nombre de personne dans les groupe (ce qui reste un peu con quand même
).
quand je regarde ton code je sais que la base ne sui pas un modèle précis, qu'il n'y a pas de respect des "normes" classique et que donc à un moment ou à un autre tu va t'en mordre les doigts.
Par exemple le fait de mettre les nom et prénom (etc) dans la table binôme, cela m'indique que tu va avoir plusieurs ligne "bob l'eponge" (par exemple).
mais aussi que cette ligne existe dans la table des élèves (et peux être ailleurs ?).
du coup si tu t'es gouré dans le nom qui est "bob léponge" il faut que tu modifie dans chaque table, pour l'utilisateur cela veux dire de passer sur tous les écrans ...
c'est fastidieux , contraignant etc.
si tu ballade une clef primaire tu ne modifie qu'a un seul endroit => gain de temps à l'utilisation mais aussi gain de temps en développement tu n'as pas copier coller le code modification de ses infos dans tous un tas de pages différentes
et en plus tu respect, au moins, la 1ère régle de codd (atomicité des informations)
si le sujet t'interesse un peu tu peux chercher un coup sur la modalisation merise (et plus particulièrement le modèle entité association), voir sur la modélisation avec UML.
@+
Il en faut peu pour être heureux ......
