Avis pour modélisation BDDFermé

Question

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 :)

yg_be · Answer

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.

jordane45 · Answer

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

patrice86 · Answer

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

Avis pour modélisation BDD

3 réponses

Discussions similaires

Newsletters