Bonjour,

j'ai une question pratique :

Je cherche à insérer dans une table 'utilisateurs' des champs 'ID_Diplome'.

Je compte créer une table 'diplomes_utilisateur' qui comptient la liste des diplômes des mes utilisateurs du style
ID - ID_utilisateurs - ID_diplomes - Numero
car mes utilisateurs peuvent avoir plusieurs diplomes différents et b ien sur d'organismes différents

Ensuite je compte créer un table 'diplomes' qui contient
ID - ID_organisme - Nom
Car il y a beaucoup de diplômes différents dans chaque organisme

et une table 'organisme'
ID - Nom

Première question : je trouve que cela fait beaucoup de table. Est-ce mieux ? Cela ne va-t-il pas trop compliquer ou augmenter le nombre de mes requêtes à la base lors de l'affichage de la fiche 'utilisateurs' (ou encore pire, à l'inscription) ?

Deuxième question: Vu que mes utilisateurs peuvent avoir plusieurs diplômes, est ce que le type de mon champs 'id_diplome' de ma table 'utilisateurs' doit être un ENUM ou est-ce qu'il ya quelque chose qui conviendrait mieux ?

Merci pour vos suggestion

july

Dans la mesure ou tu as une relation n::n entre tes utilisateurs et les diplomes (un diplome peut être associé à 0 ou n utilisateurs, et un utilisateur peut avoir 0 ou n diplomes) le mieux est effectivement d'utiliser une table intermédiaire. (donc pas d'id_diplome à ajouter dans ta table utilisateur, et donc pas besoin de chercher un type )

Dans la table que tu décris (ID - ID_utilisateurs - ID_diplomes - Numero) si l'on suppose qu'un utilisateur ne peut pas avoir deux fois le même diplome, tu peux virer le champ ID. Ta clé primaire est en effet une clé sur deux colonnes : "ID_utilisateurs, ID_diplomes".
Je ne sais pas par contre si le numéro a réellement une utilité ?

Dans tous les cas, pour connaitre la liste des diplomes d'un utilisateur, il te suffit d'interroger cette table avec l'id_utilisateur (avec id_diplome si tu veux savoir qui possède un diplome spécifique)

Pour le reste, c'est tout bon

Alors effectivement, cela t'oblige à des requêtes un peu plus compliquée puisqu'il va te falloir faire des jointures pour aller chercher les données qui te manque dans les autres tables, mais tu conserves l'unicité des données (ce qui t'évite de devoir mettre à jour une infos à 3 endroit différent, juste pour ajouter une majuscule à un diplome ) et ça c'est une bonne chose. Elles sont par ailleurs bien rangées, et c'est beaucoup plus simple de s'y retrouver plus tard (pour toi ou quelqu'un d'autre )

Pour le temps de réponse, en ajoutant des index sur tes tables sur les champs que tu utilises dans tes conditions, tu devrais compenser un peu le fait que les données soient réparties.

Merci,

tout est à peu près clair, sauf une chose : qu'est qu'une clé primaire ?

Ok, j'ai l'air nul maintenant....

D'ailleurs, si tu voulais bien m'expliquer aussi pour

Primaire, Index, unique et texte ça serait vraiment gentil de ta part

Merci

july

Une clé primaire ou primary key (PK), c'est une colonne (ou un ensemble de colonne) de ta table qui permet d'identifier chaque enregistrement de manière unique. C'est générallement un identifiant numérique du style id_utilisateur, id_forum, ... ça peut aussi être un couple "id_forum, id_message" ou autre

Une clé étrangère, c'est une colonne dont les valeurs proviennent d'une autre table. En l'occurence, dans ta table "diplome", le champ "id_organisme" fait référence à la colonne "id" de la table "organisme", c'est donc une clé étrangère (foreign key). Elles servent notamment à l'intégrité (pas encore implémenté sur mysql) en t'assurant que tu ne trouveras pas dans cette colonne une donnée qui ne sera pas rattachée à un enregistrement parent (qui aurait été supprimé, ou qui n'existe pas)

Un index, c'est un peu comme pour un livre. En gros, ta base de données va se noter sur un coin de table où sont rangés les enregistrements indexé pour les retrouver plus facilement (et donc aller plus vite lorsque tu fais un select). Si tu as un champ "login" sur ta table, à chaque fois que tu vas faire un WHERE login = 'xxx', il va scanner toute ta table pour voir s'il le (ou les) trouve. Si cette colonne est indexé, il va jeter un coup d'oeil à l'index et aller chercher directement à l'endroit indiqué. Si ta table contient beaucoup d'enregistrements, c'est des plus efficaces

Les clés primaires sont automatiquement indexées, pour te permettre de retrouver tes enregistrements, donc inutile de leur en rajouter un, en revanche, cela peut s'avérer utile sur d'autres champs régulièrement solicités, comme les clés étrangères

Ok, merci beaucoup. Ca devient très chaud pour le foetus que je suis...