Avis pour modélisation BDD
patrice86
Messages postés
1380
Date d'inscription
Statut
Membre
Dernière intervention
-
patrice86 Messages postés 1380 Date d'inscription Statut Membre Dernière intervention -
patrice86 Messages postés 1380 Date d'inscription Statut Membre Dernière intervention -
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 :)
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 :)
A voir également:
- Avis pour modélisation BDD
- Logiciel de modélisation 3d gratuit - Guide
- Sweet Home 3D - Télécharger - Architecture & Déco
- Modélisation 3d sketchup - Télécharger - 3D
- Blender modelisation - Télécharger - 3D
- Modelisation 3d iphone - Guide
3 réponses
yg_be
Messages postés
23541
Date d'inscription
Statut
Contributeur
Dernière intervention
Ambassadeur
1 584
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.
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.
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) )
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
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
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
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 :)
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 :)
