Avec un schéma c'est plus clair ..cyrano le boss lol
Bon faisons le point à mi-parcours.
Ma base ressemblera donc à ceci :

DEMANDEUR [id_demandeur*, nom, prenom, id_nationalite, id_sexe, datnaiss, datdepot, datsaisie, adress, refcv, >id_expe<]

NATIONALITE [id_nationalite*, libellenat]

TABLECV [refcv*, id_profil, id_poste, anneediplome, diplomeobt, lieudiplome]

EXPERIENCE[id_expe*, exp_debut, exp_fin, exp_type, exp_entreprise]

PROFIL [id_profil*, libelleprofil]

SEXE [id_sexe*, libellesexe]

PIECESJOINTES [id_demandeur*, refcv*, numattformation, numattstage, numdiplome]

POSTE [id_poste*, libelleposte]

Précision==> Dans exp_type, on pourra préciser : "emploi", "stage", contrat de qualif"
Dans ma tconception, les photocopies des attestations de stage, diplomes et autres pièces justificatives recevront un code/reference, et ce sont ces codes qu'on va mettre dans la table PiecesJointes. S'il ya 10 pièces jointes, on mettra les références sur la meme ligne, séparé par un espace..c'est la facon dont je compte gérer la table PJ..bonne idée?

Qqch à redire par rapport à ma bdd améliorée ?

ça centralise juste les demandes ou ça peut servir à faire un suivi ?

réponse envoyé, positive, négative, entretien ou pas, avis du/des recruteurs...

Non non, selon mes renseignements ici, les demandes, qu'elles soient acceptées ou refusées, ne sont pas zappées. On archive/classe tout..
Autre précision, ma base doit permettre d'éviter les doublons, càd s'assurer qu'une meme personne ne dépose pas plus d'1 demande pour un meme poste; mais on l'autorise toutefois à mettre à jour cette demande (précisément le cv et autres pièces connexes) au cas où il aurait par exemple eu de nouveaux diplomes...voilà koi...juste centraliser les demandes, permettre la consulation, la modification, des requetes...etc

Alors pourquoi ne pas prévoir qqchose pour stocker des infos sur les débouchés de la demande ?

ex:
- la personne a été contactée
- a passé un entretien
- commentaires : motivée, sympa, bon contact, manque d'expérience mais qualités techniques => à rappeler dans 5 ans

Pour en savoir plus quoi, je ne sais pas si c'est l'objet de ton appli

Alors pourquoi ne pas prévoir qqchose pour stocker des infos sur les débouchés de la demande ?

ex:
- la personne a été contactée
- a passé un entretien
- commentaires : motivée, sympa, bon contact, manque d'expérience mais qualités techniques => à rappeler dans 5 ans

Pour en savoir plus quoi, je ne sais pas si c'est l'objet de ton appli

Ouais c'est une idée..pkoi pas..mais ce n'est pa tellement lobjet d mon application..
L'objet de mon application, c'est dans le 1er msg de ce topic
Anyway, je suppose que pour appliquer ton idée, il suffit juste de créer un champ "commentaire" dans la table Demandeur où l'on pourra stocker des infos sur les débouchés de la demande..

Sinon, à part ça, tu trouves que ma bdd est bien modélisée? mm si ce n'est pas encore la perfection?
Si oui, je pourrai alors passer à la définition des cardinalités entre les associations

Vos avis sur mon modèle (en haut) attendus...

Fais un schéma, scanne-le et mets l'image en ligne quelque part pour qu'on puisse se faire une idée, ce sera plus facile pour te répondre à mon avis.

Fais un schéma, scanne-le et mets l'image en ligne quelque part pour qu'on puisse se faire une idée, ce sera plus facile pour te répondre à mon avis.

Tu veux dire le schéma de la base montrant les relations et cardinalité je suppose exact?

Voilà

Jusque là, je suis tjrs entrain de réfléchir sur les relations et les cardinalités..d'ici là, si je finis, je vais le proposer ici.

A propos, comment faire une relation entre des tables avec phpMyadmin? Tout ce que je réussi à faire, c'est juste créer les tables, définir leur structure, mais j'arrive pas (comme dans Access) à créer de relations entre clés primaires et clé étrangère...Ou bien cela n'est possible qu'avec un code sql

MySQL ne gère pas l'intégrité référentielle, sauf si tu prends le type InnoDB pour tes tables

sinon c'est dans le code que tu gères toi-même ça

Pour ça, tu dois créer des tables de type InnoDB, l'intégrité référentielle n'est pas supportée par les tables MyISAM. Ensuite, sélectionne les tables une par une et regarde en dessous de la structure, tu as des liens dont un "Gestion des relations". Attention, ça ne crée pas les clés étrangères automatiquement, elles doivent être définies à l'avance dans les tables liées.

Attention, ça ne crée pas les clés étrangères automatiquement, elles doivent être définies à l'avance dans les tables liées.

Tu veux dire lors de la définition de la structure de la table je suppose; càd les champs à lier doivent avoir la meme structure et le meme nom..exact ?

Autre chose, j'ai essayé de faire ce que tu as dit, mais je ne vois pas tjrs comment créer les clés étrangères

Non, pas obligatoirement. Ce que je veux dire, c'est que en ouvrant ça, tu vas avoir un formulaire et tu devras choisir vers quel champ de quelle table tu veux relier. Mais si le champ de destination n'existe pas, tu ne pourras pas faire le lien.

Donc en créant tes tables, elles devront avoir les champs correspondant aux clé étrangères.