|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité de passage
![]() Inscription : mars 2011 Messages : 2 ![]() |
Bonjour,
Je débute en base de données et je suis perplexe concernant la concrétisation dans la base d'une relation réflexive. Je cherche à permettre à des utilisateurs définis par un Id (PK) de ma table USER de "s'abonner" à d'autres USER. J'aurais donc une table USER avec une autre table ABONNEMENT qui je pense comporterait pour clé primaire la concaténation des deux Id des USERS dans le sens Id.de.l'abonné#Id_User_Suivi. Là où je bloque c'est sur le traitement ultérieur des données. Prenons par exemple le user 845 qui suit le user 1567, la concaténation donnera donc 8451567. Comment reconnaitre dans le traitement l'id de l'abonné parmi cette suite de chiffre ? Placer un point entre chaque Id, tel que 845.1567, et donc avoir un type VARCHAR pour cet attribut ? (ça ne ralentirait pas drastiquement les temps de traitement?). Merci pour vos idées sur cette question (qui peut parait farfelue, il existe peut-être des solutions beaucoup plus simple...) |
|
|
00
|
|
|
#2 |
|
Membre Expert
![]() Inscription : août 2008 Messages : 1 271 ![]() |
La concaténation de PK est une mauvaise idée, indépendamment des perfs.
La table abonnement aura 2 colonnes : abonnemnent (id_user,abonne) par exemple où (id_user,abonne) est une PK ou au minimum une Uk (contrainte d'unicité) car 1 user ne peux s'abonner qu'à un autre user distinct (et pas plusieurs fois au même user) Par ailleur "id_user" et "abonne" seront des clés étrangères de la table user pour éviter qu'un user puisse s'abonner à un user qui n'existe pas. Donc il y aura abonnement(845,1567) mais aussi (845,1578) .... et comme ça tout sera plus simple |
|
|
00
|
|
|
#3 |
|
Invité de passage
![]() Inscription : mars 2011 Messages : 2 ![]() |
Merci pour ta réponse.
Si je comprends bien, pas tu préconises une table Abonnement avec en PK un Id_Abonnement (du type auto_increment) et deux attributs Id_User et Id_User_Suivi. C'est bien ça ? Edit: non, ça ne doit pas être ça: tu parles d'une PK formée par les deux attributs. Une PK peut être composée de deux colonnes ? (oui, je suis une bille en BDD) Edit2: Primary keys can also constrain more than one column; the syntax is similar to unique constraints: PRIMARY KEY (a, c) Je crois que c'est plutôt ça |
|
|
00
|
|
|
#4 |
|
Membre Expert
![]() Inscription : août 2008 Messages : 1 271 ![]() |
Oui c'est pluôt ça, mais si la table abonnement est reliée à d'autres tables (autre que user) alors tu peux avoir une PK autoincrémentée et dans ce cas il faut créer une contrainte d'unicité sur (id_user,id_user_suivi) de la table abonnement, tout dépend du modèle dans sa totalité.
|
|
|
00
|
|
|
#5 | |
![]() ![]() |
Citation:
On peut très bien propager une clé primaire multi-colonnes en clé étrangère dans d'autres tables.
__________________
Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework... « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau) À la maison comme au bureau, j'utilise Mandriva Linux ou Mageïa ! Soutenons l'industrie logicielle française ! Linuxiens, comptez-vous ! |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com