Vous n'êtes pas identifié(e).
Bonjour,
Dans le cadre de la mise en place de ma structure de base de donnée sur papier à l'heure actuelle, je me pose une question supra basique.
Admettons un cas exemple avec 2 tables
1) Etablissement
id_etab
2) Projets
id_projet
je créer une relation n:m car un etab peut participer à plusieurs projets et 1 projets fait intervenir plusieurs etab
jusque la je ne pense pas faire d'erreur!
ma question est la suivante : 1 etab peut être soit coordinateur d'un projet, soit sous contractant simple participant etc.
dans notre table de liaison
j'aurai donc!
id_etab
id_projet
statut
dans le cadre d'une programmation correct, le champ statut vous mettriez quoi?
- un enum avec une liste défini de possibilité?
- 1 champ int avec un numéro ?
En effet je me pose cette question car:
1) les possibilités peuvent évoluer dans un cas autre et il faudrait donc modifier l'enum
2) admettons un site multilingues l'enum ne sera pas correct pour les langues autres que celle indiquée.
merci de me donner votre avis car ce simple truc me dérange!
merci d'avance
Hors ligne
Bonjour,
Dans un contexte évolutif et pour préserver l'atomicité des données, un champ numérique non signé pour le statut sans aucun doute.
Après pour ta modélisation, reste à savoir si un même établissement pour un même projet peut y intervenir à plus d'un titre ou qu'à un seul et unique titre.
++
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
merci pour ta réponse!
un établissement et pour un projet ne peut intervenir qu'a un un seul titre.
aussi je vais opter pour un champ numérique de forme tinyint(1), serait ce adapté?
par contre vais me renseigner sur le signé ou non signé car je ne connais pas la différence!
Dernière modification par Darkangel (14-12-2011 10:59:30)
Hors ligne
Apres verif je comprend mieux mais il me reste un poit
mieux vaut utiliser tinyint ou comme cela est indiqué à plusieurs endroits boolean??
Hors ligne
Saluton,
Autre possibilité, si évolutivité véritable, créer une table des statuts dont l'identifiant deviendrait une clé étrangère dans la table de liaison.
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
ouais bien vu vais voir ca!
par contre autre question !
j'ai une table
Etablissement
1 table groupe Identifiants
je fais une liaison n:m entre etab et identifiants afin que 1 etab puisse avoir plusieurs groupes et qu'un groupe puissent etre liés à plusieurs étab.
d'ou une table de liaison appelée Etab has Groupes
ma question est la suivante:concernant ma table d'identifiants sommes nous bien d'accord qu'il me faut la lier à ma table nouvellement crée par un n:m appele style Identifiants in Etab has Groupe.
de sorte à avoir in fine une table avec
id groupe
id etab
id identifiant.
ca serait ok comme cela?
Hors ligne
Saluton,
Autre possibilité, si évolutivité véritable, créer une table des statuts dont l'identifiant deviendrait une clé étrangère dans la table de liaison.
Ce qui au final correspond a l'approche via un int (tiny ou pas), qui au final n'est qu'une sorte de clé (utilisée dans le code visiblement dans ce cas), sauf que tu indique la modélisation correcte.
Ceci dit, par habitude au niveau des performances, je crois que j'aurai tendance a garder la correspondance dans le code, ou bien a faire en sorte que la table des status soient traduit dans le code (sans doute par un tableau), parce que l'utilisation de cette table rajoute une jointure, et par expérience, les jointures, faut savoir limiter un jour ou l'autre (je parle là bien de pratique, pas de théorie).
La dualité de vision développeur/administrateur serveur, c'est terrible
@+
la v2, c'est tabou, on en viendra tous a bout
Hors ligne
Saluton,
Autre possibilité, si évolutivité véritable, créer une table des statuts dont l'identifiant deviendrait une clé étrangère dans la table de liaison.
C'était le but dans ma proposition (merci Manicow ). En effet un id_statut dans la table de jonction dans un contexte normalisé, n'a pas d'intérêt si cela n'est pas vu ainsi.
D'où la réponse également à darkangel : si tu mets un boolean tu n'as que deux valeurs possibles, aucun intérêt donc en terme d'évolutivité. un tinyint unsigned est un minimum pour commencer.
à manicow: les jointures ne posent pas de problèmes en général, c'est plutôt à mon humble avis la gestion des indexs et les techniques employées dans les requêtes qui sont la source des pb de performances.
++
Dernière modification par Jc (14-12-2011 13:31:57)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
à manicow: les jointures ne posent pas de problèmes en général, c'est plutôt à mon humble avis la gestion des indexs et les techniques employées dans les requêtes qui sont la source des pb de performances.
++
Il y a en effet aussi une partie du problème sur les index, leurs gestions, leur optimisations, et sur les requêtes tout court. Néanmoins, plus ta requête a de jointure, plus c'est complexe, que cela pour les index mais aussi pour mysql (qui a beau essayer d'optimiser l'ordre de sélection dans les tables, n'arrive pas toujours a tout). Et au final, plus ça charge (et crois moi des mysql et des requêtes, j'en ai vu passé depuis le temps, sur des serveurs qui prennent cher parfois).
Donc au final, quand une table ne change qu'une fois tout les 3 ou 4 mois, j'ai tendance a me débrouiller pour la faire sortir de mes jointures Il n'y a pas de petites optimisations quand il s'agit de gros sites
la v2, c'est tabou, on en viendra tous a bout
Hors ligne
ok merci pour vos commentaires:
je vais donc suivre vos conseils!
quelqu'un pour mon dernier post sinonµ?
merci à vous en tout cas!
Hors ligne
Bonjour,
Au fait, j'avais oublié de répondre à la question. tinyint(1) et bool c'est la même chose dans mySQL. Le bool est défini par mysql pour assurer la compatibilité avec les autres SGBDR.
++
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne