Avis pour modélisation BDD
Fermé
patrice86
Messages postés
1378
Date d'inscription
dimanche 26 octobre 2008
Statut
Membre
Dernière intervention
26 novembre 2023
-
Modifié le 13 sept. 2019 à 16:14
patrice86 Messages postés 1378 Date d'inscription dimanche 26 octobre 2008 Statut Membre Dernière intervention 26 novembre 2023 - 19 sept. 2019 à 11:16
patrice86 Messages postés 1378 Date d'inscription dimanche 26 octobre 2008 Statut Membre Dernière intervention 26 novembre 2023 - 19 sept. 2019 à 11:16
A voir également:
- Avis pour modélisation BDD
- Outil modélisation base de données gratuit - Télécharger - Bases de données
- Blender modelisation - Télécharger - 3D
- Logiciel modelisation maison 3d - Télécharger - Architecture & Déco
- Modélisation 3d sketchup - Télécharger - 3D
- Logiciel de modélisation 3d gratuit - Guide
3 réponses
yg_be
Messages postés
22720
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
23 avril 2024
1 476
13 sept. 2019 à 18:19
13 sept. 2019 à 18:19
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.
jordane45
Messages postés
38144
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
21 avril 2024
4 650
13 sept. 2019 à 18:42
13 sept. 2019 à 18:42
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
patrice86
Messages postés
1378
Date d'inscription
dimanche 26 octobre 2008
Statut
Membre
Dernière intervention
26 novembre 2023
125
15 sept. 2019 à 01:08
15 sept. 2019 à 01:08
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
jordane45
Messages postés
38144
Date d'inscription
mercredi 22 octobre 2003
Statut
Modérateur
Dernière intervention
21 avril 2024
4 650
15 sept. 2019 à 08:41
15 sept. 2019 à 08:41
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 ...
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
1378
Date d'inscription
dimanche 26 octobre 2008
Statut
Membre
Dernière intervention
26 novembre 2023
125
19 sept. 2019 à 11:16
19 sept. 2019 à 11:16
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 :)