Bonsoir tout le monde,

J'ai fait un MDC et je voudrais savoir votre avis surtout au niveau de la table "person" et "password",  j'ai choisi de faire une table "password" à part puisqu’un candidat est une personne, mais il n'a pas forcément de mot de passe.

Le contexte :

Un candidat peut devenir une hôtesse après avec été recruté, il peut avoir un simple rôle d'hôtesse ou être un contributeur, une personne peut être une hôtesse ou un admin.

-
Edité par snapzcorp 1 octobre 2021 à 17:02:40

Bonjour,

J'ai du mal à identifier quelle est ta question ...

Je mettrai un héritage au niveau de person (entité mère) qui donne deux enfants "candidat" et "utilisateur". Le password serait dans l'entité utilisateur, et le rôle également lié à cette entité et non à person.

Candidat serait tojours parent de Hostess par héritage.

Au passage, entre candidat et hostess un héritage X (exclusion) est nécessaire, le T (totalité) est en trop (tous les candidats ne sont pas des hostess).

Enfin, rien à voir, mais je suis curieux de voir ce qui est à droite de l'héritage T de availability ... Déjà une entité pour stocker une date c'est étrange, et que peut-on hériter d'une date ?

Bonjour,

Benzouye a écrit:

Bonjour,

J'ai du mal à identifier quelle est ta question ...

Je voulais savoir si le MCD présentait des erreurs de création notamment au niveau de la table "password".

Benzouye a écrit:

Bonjour,

Je mettrai un héritage au niveau de person (entité mère) qui donne deux enfants "candidat" et "utilisateur". Le password serait dans l'entité utilisateur, et le rôle également lié à cette entité et non à person.

J’ai fait plus simple, j'ai retiré la table "password" et j'ai mis le mot de passe dans "person". J'ai gardé l'association entre personne et candidat, personne et rôle.

Benzouye a écrit:

Au passage, entre candidat et hostess un héritage X (exclusion) est nécessaire, le T (totalité) est en trop (tous les candidats ne sont pas des hostess).

Enfin, rien à voir, mais je suis curieux de voir ce qui est à droite de l'héritage T de availability ... Déjà une entité pour stocker une date c'est étrange, et que peut-on hériter d'une date ?

Oui j'ai retiré le T sur l'héritage. et je t'ai mis le reste du MCD, ce sont des heures qui héritent d'une date.

-
Edité par snapzcorp 1 octobre 2021 à 17:02:52

C'est dingue je trouve. Tu utilises les types DATE et DATETIME et à première vue c'est logique, mais pour les heures, tu choisis un VARCHAR. Pourquoi ne pas utiliser le type TIME ?

En lisant rapidement, tu ne respectes pas la 1NF. social_security_number : voir là, address : pareil.

Une adresse c'est, généralement :

Numéro de voie | type de voie | nom de la voie | département sur 5 chiffres (à séparer en 2 : département et le reste à 3 chiffres*) | Ville

* si tu veux tous les Parisiens du Xème, tu cherches les 75 puis le code 010 => 75010

CristianoRolando a écrit:

C'est dingue je trouve. Tu utilises les types DATE et DATETIME et à première vue c'est logique, mais pour les heures, tu choisis un VARCHAR. Pourquoi ne pas utiliser le type TIME ?

J'ai mis en VARCHAR, puisque je me suis dit que c'était plus facile à gérer, mais réflexion faite .... je pense que, je vais utiliser TIME.

CristianoRolando a écrit:

En lisant rapidement, tu ne respectes pas la 1NF. social_security_number : voir là, address : pareil.

En quoi je ne respecte pas, mes données sont uniques. L'adresse est stockée en json il a bien le numéro, adresse, la ville .... Et pour social_security_number je ne te cache pas je ne vois pas où il est le problème.

snapzcorp a écrit:

J'ai mis en VARCHAR, puisque je me suis dit que c'était plus facile à gérer, mais réflexion faite .... je pense que, je vais utiliser TIME.

Très bonne réflexion, je ne trouvais pas logique ta première décision.

Je n'ai pas vu, auparavant, que tu stockais en JSON. Ne trouves-tu pas que tu doubles le système de stockage (JSON + SQL) ? Et donc, l'un ou l'autre est inutile ?

Éclater l'adresse comme j'ai dit dans SQL c'est possible, et JSON n'a pas d'intérêt dans ce cas.

concernant le numéro de sécurité sociale, je t'enjoins à lire ce lien. Normalement, tu comprendras, surtout que ça provient d'une personne qui a des dizaines d'années d'XP en BDD.

Si j'ai bien compris, il faut que je crée une table pour le numéro de sécurité social et pareil pour l'adresse ?

-
Edité par snapzcorp 28 septembre 2021 à 20:43:20

J'ai fait un test et relu le lien (commentaires compris) que je t'ai envoyé. J'ai dumpé (= exporté) mes 2 BDD. Une qui était monotable avec l'adresse sur une colonne en Varchar, et une autre BDD en séparant les éléments de l'adresse. J'ai inséré seulement 4 lignes avec 2 rues (il y a doublons). Et verdict, la BDD multitable est plus lourde, sans doute parce qu'il doit y avoir un coût constant par table créée.

Donc, en lisant les commentaires, j'ai lu que parfois dénormaliser comme tu fais peut avoir du bon. Par exemple, si tu es certains de ne pas vouloir faire des stats pour savoir combien de Franciliens sont candidats en France, tu peux conserver l'adresse en 1 colonne.

Maintenant, je conseille de normaliser pour pratiquer, si jamais, tu fais des stats sur une BDD, avec un langage de prog et une BDD normalisée tu pourras automatiser beaucoup de tâches.

Ok, merci pour ton aide, je pense que je vais laisser l'adresse comme ça, puisque je ne fais rien de spécial avec à part l'affiché sur des documents. Pour le numéro de sécu ça peut être intéressant pour recherche les hommes ou les femmes.

Concernant les performances sur la multitable je lavais déjà vu, mais c'est minime, donc ça ne se ressent pas vraiment

-
Edité par snapzcorp 30 septembre 2021 à 22:27:00