Création d'un MCD

@Pouki: C'est le schéma de ta base de données ou de ton applicatif ?
Quelles que soient les situations rencontrées, il ne faut JAMAIS mettre des noms au hasard. Sauf aux endroits ou tu le souhaites précisément et où tu le sait.
Normalement tu n'auras pas besoin de faire appel à un index, c'est utilisé dans le moteur de gestion de base de données.

@NoxWorld: C'est juste le schéma que j'ai modélisé avec DBDesigner.

@Pouki: Je comprends pas bien la distinction que tu fais entre Examen / Session d'examen / Certifications.

Pour moi t'as une table de trop ou un lien à l'envers, je m'explique : Un examen sera organisé => session d'examen, pour obtenir une certification précise (j"imagine du moins, je ne connais pas les détails, arrête moi si c'est faux).
Auquel cas je vois pas pourquoi t'as besoin de séparer en autant d'éléments... Pour moi, ce serait une session d'examen (id, date_debut, duree) qui serait organisée pour une certification (id, nom, description, ... ) Et certificats obtenus irait rechercher une référence vers Certification.
En ce qui me concerne, je vois pas pourquoi t'as Reference examen et encore moins date.

Tes champs " référence " n'ont absolument aucun sens : l'id est déjà un identifiant unique, donc si t'as besoin d'une référence, tu fais référence à ça^^
A moins que pour des raisons interne à l'entreprise on te demandes de mettre des références avec des lettres du type : " CERT-A-12".

@Pouki: PS : MCD ? Modèle Conceptuel de Développement ? :o
Parce que ça pour moi, c'est un schéma UML avec quelques normes bafouées :)

@NoxWorld: Ce que l'on appelle "session d'examen", c'est un groupe "d'examen", se déroulant la même semaine, dans le même centre d'examens.
Typiquement, un "examen" dure une demi journée, pour 10 candidats, utilise 1 salle et 2 personnes du "staff" pour l'encadrement.
Mais suivant les centres d'examens et les disponibilités, on a accès a 1,2 voir 3 salles d'examen en parallèle, sur le même site, et donc on fait appel à 2,4 voir 6 membre du staff pour encadrer les examens.
Donc pour x personnes qui passent l'examen sur la même session, on peut avoir plusieurs personnes différentes pour l'encadrement. Je souhaite garder cette information en cas de litige/contestation pour pouvoir discuter avec les personnes concernées.

Quand aux champs référence, c'est effectivement une information redondante, mais que l'on a utilisé historiquement. ils sont marqués sur les convocations et les attestations de présence actuelles, et de manière générale sur tous nos documents officiels. J'ai préféré me laisser le choix de continuer de les utiliser et voir comment ça évolue avec ce nouveau outil, quitte a ne plus les utiliser par la suite.

EDIT: du coup, je devrais rattacher les tables examinateurs et contrôleur à la table examens et non à certificats car tous les candidats du même examen ont le même staff encadrant

@NoxWorld: Edit 2 : de même pour un seul "examen" correspond à une seule certification. Donc je ferais mieux relier la table "certifications" à la table "examens". Mais bordel c'est un vrai casse tête.

@Pouki: Oui c'est un casse tête. Y'a une information aussi qui est très redondante, c'est les infos personnelles du staff et des participants. Perso je ferais une table "personnes" avec les informations générales, et puis une table staff (reference à id de personne + informations uniques au staff) et pareil pour les participants (référence à id de personne + informations uniques au participants). PS : Le staff peut il éventuellement passer des examens ?
PS2 : corrige déjà les 2 ou 3 petites choses, ça sera un peu plus clair sur le schéma normalement vu qu'il y a moins d'informations redondantes, et renvoie nous le screen.

@Pouki: Je vois pas très bien ce que c'est un salarié d'entreprise par rapport aux participants non plus, encore une fois j'ai l'impression que c'est redondant (nom & prenom de salarié qui se retrouvent déjà dans la table participants non ? D'ou l'intéret de faire une table personne ^^) mais je peux me tromper vu que je ne sais pas à quoi salarié correspond :)
Bon courage ! Et conseil d'ami, ne grossis pas les fonctionnalités, garde ça très simple, autant que tu le peux. C'est déjà une galère comme ça.

@NoxWorld: Merci pour ses éléments de réflexion, ça m'aide beaucoup. Après une nuit à cogiter, effectivement je me suis compliqué la vie avec les tables examens/session d'examen. J'étais trop focalisé a vouloir reproduire le fonctionnement de mon tableau excel. J'ai donc
- supprimé ces 2 tables. Si j'ai besoin de codes d'identifiant unique pour la paperasse, je les générerais avec les id.
- créé une table planning.
- renommé la table "adhérents" en "utilisateur (de mon outil)" . Car c'est une entreprise que adhère, et non pas une personne. Par-contre l'utilisateur est forcement salarié d'une entreprise adhérente.

A ce titre:
- un utilisateur peut avoir des certifications, mais ça reste très rare, le plus souvent il s'agit d'une secrétaire.
- Les personnes du staff ont au moins une certification, mais par-contre ne sont pas forcement salarié. Et Ils ne dépasseront probablement jamais le nombre de 15.

Je suis donc entrain de voir pour rassembler tout le monde (salariés certifiés/utilisateurs du logiciel/membre staff) dans une même table et faire des tables intermédiaires, comme tu me l'a suggéré. A voir si c'est un plus dans mon cas (j'en doute un peu pour le moment)

Voici où j'en suis:

@NoxWorld:
Tableau résumant le type de personnes en base et les infos que j'ai besoin de retenir. Et aussi une idée de la quantité.

@Pouki: Autre compte, j'ai encore oublié mon mdp, mais je me suis souvenu de l'autre .... -__' ...

Moi je mettrais l'information email dans les salariés aussi, c'est toujours utile pour envoyer une notification ou simplement si tu en as besoin pour contacter en cas de pépin, d'annulation, de n'importe quoi. (Même si tu le codes pas et que tu t'en sers pas niveau fonctionnalité , c'est intéressant d'avoir l'info me semble.)
Pour moi adresses et Telephone c'est des tables séparées. et tu fais une table de liaison (si y'a plusieurs adresses ou tel possibles) ou une simple référence (si t'es sur & certain que ce sera toujours 1 tel par exemple ou 1 adresse)

@Pouki: Je penses que t'as l'impression que faire plus de table te compliques la tache, mais penses bien qu'une table avec plus de 10 champs c'est très lourd, surtout au niveau des requêtes et des tris.
Enfin l'idée c'est d'éviter les informations redondantes, et que faire des tables d'adresses et de téléphone ça te permet de réutiliser l'information si la personne est encodée ailleurs dans le système, du coup ça évite les doublons sur le long terme aussi.

Après si t'es pas à l'aise avec les requêtes SQL qui risquent d'en découler, ne pousses pas trop non plus. Et par pitié , ne fais pas de cross join (SELECT * FROM personnes, salarié, examens WHERE ... ORDER BY ...).

Sinon je pense que ca a bien avancé, ça prends forme.

Commentaire supprimé.

@No_Offense: @NoxWorld: Ok donc,tu n'a pas tord.
J'ai fait une table infos qui contient tout les champs possibles dont je peut avoir besoin et je la lie aux différentes table. Je l'utilise même pour les centres d'examens.
Au final ça me complexifie un peu l'écriture des requêtes, mais je gagne en flexibilité pour l'avenir.

Je connais pas la commande CROSS JOIN, ça m'a l'air spécial...
Non moi pour récupérer des données dans x tables, en une seule requete, j'ai toujours utilisé INNER JOIN. par exemple:

*SELECT
agences.id,
agences.nom AS nom_agence,
agences.adresse,
agences.code_postal,
agences.ville,
agences.telephone,
entreprises.nom AS nom_entreprise
FROM
agences
INNER JOIN
entreprises
ON
agences.id_entreprises = entreprises.id
WHERE
agences.id_entreprises = :id*

C'est une bonne méthode ou il y a mieux ?

@Pouki: Inner join est une très bonne méthode, le cross join est à éviter, t'auras parfois besoin de faire des LEFT / RIGHT JOIN.
En gros la syntaxe : SELECT * FROM personnes LEFT JOIN membres ON personnes.id = membres.id_personnes.

Il va te sortir tous les résultats des personnes et des membres dans le cas où l'id de personne est aussi l'id_personne de la table membres.

J'ai pas d'exemple concret, mais c'est beaucoup plus utilisé que l'inner join qui risque parfois d'omettre des résultats.

Pour la table infos, faut voir mais c'est pas forcément opti non plus : ça sert à rien de faire une table info avec 12 champs si tu va en remplir 6 par entrées...

@No_Offense: Me voila pas plus avancé sur ou foutre mes coordonnées.

@Pouki: Table personnes, table telephones (id, telephone en varchar, un commentaire ou une énumération pour savoir si c'est fixe ou privés - peut être même deux tables : tel_portable & tel_fixe), table adresses (id, ligne1,ligne2, Departement, Code postal , pays) et des tables de liaisons entre. telephones_personnes (id_personnne , id_telephone).

J'éviterais de faire 2 tables téléphone quand même, sauf si c'est sur et certain que tu n'auras que ces 2 types de numéros et que c'est 1 fixe 1 gsm (et encore).

Je ferais donc un lien entre téléphones & personnes via une table de liaison, idem pour adresses, et si t'as pas besoin de l'info, tu met pas d'entrée dans ta table de liaison, np pas de soucis.

@Pouki: NB : je t'ai donné des exemples de champ entre parentheses, mais c'est à ton appréciation hein. Je te conseille tout de même fortement de garder 2 lignes pour l'adresse (des fois y'a des noms à rallonge) et de mettre le téléphone en varchar (dans certains pays les préfixes téléphoniques ou régionaux peuvent être des lettres, qui sait si ça arrivera chez nous ou si tu travailleras peut etre avec un mec qui vient de loin).

Plus clair ? :)

@No_Offense: Ok ok, je prend note.
- J'aime l'idée de la table 'personnes' mais j'ai un problème avec son nom. En effet, je la lie aussi avec mes centres d'examens et les agences, donc je préfère appeler 'annuaire' (ou un truc du genre)
- j'ai fait 3 champs 'adresse_' car certaines des agences en ont besoins
- le champ 'telephone' est en varchar(14) car à en croire wikipedia, au maximum un indicatif téléphonique c'est +xxxx. Donc (+xxxx xxxxxxxxx) = 14 (sans l'espace)
- Je pense avoir résolu le dilemme "faut t'il faire 2 tables pour téléphone fixe et mobile". J'ai fait 2 clé étrangères dans la table annuaire, liées à une seule et même table 'telephones'

C'est de moins en moins dégueulasse non ?

@Pouki: J'aurais pas fait le regroupement Telephone / Adresse parce que t'auras pas toujours forcément les deux infos ensemble (M'enfin, ça c'est toi qui le sait en vrai^^)
Met un varchar 20 pour le téléphone, on nsait jamais. (Prefix, trucs internes a lentreprise etc etc)