Avis pour modélisation BDD

Messages postés
1352
Date d'inscription
dimanche 26 octobre 2008
Statut
Membre
Dernière intervention
19 septembre 2019
-
Bonjour,

En projet pour développer une application sous SF, j'aimerais avoir vos idées de modélisation pour le point suivant.

Application pour des vendeuses de réunion à domicile.
Un carnet de contact Client. Un client est une personne qui participe aux réunions.
Une réunion à lieu chez un Hôte (qui est à la base un client).
Une réunion contient un ou des clients, elle est liée à un seul hôte.


L'idée étant qu'un client peut à tout moment devenir un hôte en décidant d'accueillir une réunion chez lui.
Un hôte peut également être un client dans le sens où il peut participer à une réunion chez un autre hôte
La différence entre un hôte et un client, un champ en plus options au format json, une distinction importante pour la vendeuse dans le sens où elle fait des relances auprès des hôtes pour savoir si ils souhaitent accueillir une nouvelle réunion et fait de la fidélisation des hôtes avec des remises, cadeaux...
Il faut donc cette distinction.

Comment feriez-vous cette distinction ?

J'hésite entre
- faire une table client et une table hôte
- une seule table client avec un champs "type" avec en valeur "client" ou "hôte" et mes requêtes se baseront sur ce champs
- une table client et une table statut avec tous les statuts possibles (client, hote, peut etre d'autres statut demain)

Merci :)
Afficher la suite 

3 réponses

Messages postés
8536
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
19 septembre 2019
424
0
Merci
bonjour,
Moi je ferais une table Personnes et une table Hôtes.
Un hôte serait bien sûr enregistré dans la table Personnes. La table Hôtes aurait un champ avec l'identité de la personne (un champ unique de la table Personnes), et des champs spécifiques aux hôtes.
Si il n'y a(ura) pas de champ spécifique aux hôtes, alors je ferais uniquement une table Personnes, dans laquelle j'aurais un champ booléen (oui/non) pour indiquer s'il s'agit d'un hôte ou pas. Je préfère un/des booléen(s) plutôt qu'un statut, cela me semble plus flexible dans ce cas.
Commenter la réponse de yg_be
Messages postés
26314
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
19 septembre 2019
1786
0
Merci
Bonjour,

Déjà.. tout dépend si une personne peut avoir plusieurs status ou non.
et/ou... si il y a d'autres status que "hote" ou "client" (comme tu le dis << peut etre d'autres statut demain >> )

Avec ce que tu décrit pour l'instant.. ta seconde proposition semble la plus adaptée.
- Une table "personne" ( id, nom, prenom, adresse, cp, ville, mail, id_statut ,tel... )
- Une table "statut" (id, libelle )

Tu peux aussi ne faire qu'une seule table
- Une table "personne" ( id, nom, prenom, adresse, cp, ville, mail, statut ,tel... ) avec le champ statut de type "ENUM" (mieux que du booleen )


Par contre, si une personne peut avoir "plusieurs statuts" .. dans ce cas ça devient
- Une table "personne" ( id, nom, prenom, adresse, mail, cp, ville, tel... )
- Une table "statut" (id, libelle )
- Une table "personne_statut" ( id, id_personne, id_statut ) ( Une personne peut avoir 1->n statut(s) )
  • les champs "id'" sont des clés primaires Auto-incrémentées




Commenter la réponse de jordane45
Messages postés
1352
Date d'inscription
dimanche 26 octobre 2008
Statut
Membre
Dernière intervention
19 septembre 2019
101
0
Merci
Bonsoir,

Merci pour vos réponses :)
Les hôtes auront des champs spécifiques (points fidélité, jour préféré au format json). C'est champs là ne seront pas pour les simples clients. Il me faut donc une table séparée je pense afin de rendre les deux champs obligatoires pour les hôtes.

ça veut dire :
- réunion
- client
- hôte
- commande (j'avais oublié d'en parler, hôte et client peuvent passer des commandes

Lorsque je vais créer une réunion, je vais donc chercher dans la table hôte pour remplir le champ adéquate et chercher dans les deux tables hôte et client pour le champs "client présent".
Idem pour les commandes, j'irai chercher dans les deux tables.

ça me semble être le plus en réponse avec mes besoins et ça correspond à vos idées.
Si vous avez des idées d'améliorations, n'hésitez pas ;)

Merci
jordane45
Messages postés
26314
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
19 septembre 2019
1786 -
J'insiste...
Une seule table pour gérer les "personnes" suffit.
Par contre, rien ne t’empêche d'avoir ensuite des tables complémentaires pour stocker les "autres informtations" spécifiques.

Ca t'évitera pas mal d'erreurs lorsque tu souhaiteras changer le "statut" d'une personne ...
patrice86
Messages postés
1352
Date d'inscription
dimanche 26 octobre 2008
Statut
Membre
Dernière intervention
19 septembre 2019
101 -
Bonjour
Je suis parti sur une seule table personnes avec une distinction boolean isHote pour les différencier.
En Symfony, je vais utiliser les annotations pour faire les validations par groupe avec un callback pour indiquer par exemple que le champs point est obligatoire pour les "personnes" qui ont le champs isHote a true.

Merci :)
Commenter la réponse de patrice86