Bonsoir,

J'ai un petit souci pour la conception de ma base de données.

Dans mon application, j'ai des mécaniciens et des candidatures de mécaniciens qui ont les mêmes infos (nom, prénom...). Dans ma base de données, je ne sais pas comment faire pour récupérer les infos sans faire de doublon.

Si je fais 2 tables, ça sera un doublon.

Si je fais de l'héritage les 2 tables enfants seront vides.

Je ne sais pas comment faire, ni comment marche une réflexive, donc je ne peux pas l'utiliser.

Est-ce que quelqu'un pourrait m'aider à y voir plus clair ?

Pour te répondre sur ce que tu appelles la réflexive soit une relation entre éléments d'une même table, le fonctionnement ne change pas d'une relation entre 2 tables distinctes.

On crée une relation lorsque la cardinalité la plus élevée est supérieure à 1 dans les 2 sens.

Exemple :

Table HUMAINS :
id_humain Clé Primaire
prénom_humain;
nom_humain.

Table de relation AFFILIER qui part de HUMAINS vers HUMAINS :
# id_parent fait référence à HUMAINS.id_humain;
# id_enfant fait référence à HUMAINS.id_humain;

---

id (5012) Alice BERNARD est la mère de id (5025) Bob DURAND 

Tu inséreras l'id 5012 et l'id 5025 dans la table de relation AFFILIER

Comme idée, tu pourrais ajouter une colonne booléenne (VRAI si mécano, FAUX si candidat). Si tu fais de l'héritage, tu auras 2 tables enfants qui contiennent l'id du parent et la colonne booléenne qui sera toujours VRAI pour les mécanos et FAUX pour les candidats. Donc, au final, je pense que le mieux est l'ajout d'une colonne booléenne car ton problème est binaire (on est mécano ou on ne l'est pas).

Bonjour,

L'idée de la colonne booléen est la plus simple : une seule table avec une colonne valant 0 ou 1 en fonction ...

Sinon, l'héritage serait le plus propre :

• candidat ( id_candidat [pk], nom, prenom, etc. )
• mecanicien ( id_mecanicien [pk][fk], date_embauche, etc. )

Dans la table mécanicien, la clé primaire est aussi clé étrangère vers la table candidat.

Benzouye a écrit:

Sinon, l'héritage serait le plus propre :

• candidat ( id_candidat [pk], nom, prenom, etc. )
• mecanicien ( id_mecanicien [pk][fk], date_embauche, etc. )

Dans la table mécanicien, la clé primaire est aussi clé étrangère vers la table candidat.

Est-ce parce que tu en déduis qu'un mécano était candidat auparavant ?

Oui, un mécanicien est forcément candidat avant d'être mécanicien.

Benzouye a écrit:

Sinon, l'héritage serait le plus propre :

• candidat ( id_candidat [pk], nom, prenom, etc. )
• mecanicien ( id_mecanicien [pk][fk], date_embauche, etc. )

Dans la table mécanicien, la clé primaire est aussi clé étrangère vers la table candidat.

Niveau performance est-ce que ça va se sentir ou c'est trop minime pour qu'il est une quelconque répercussion ?

snapzcorp a écrit:

Niveau performance est-ce que ça va se sentir ou c'est trop minime pour qu'il est une quelconque répercussion ?

C'est à dire ? Quelle sera la volumétrie de ces deux tables ?

Si les tables sont volumineuses (plusieurs dizaines de millier d'enregistrement), du moment que les index sont bien il n'y a pas de raison ...

Non elles ne seront pas très volumineuses. Merci