Discussion :

[Balbuzard]

Bonjour!

Je cherche dans la partie administration de Django à modéliser des utilisateurs qui sont autorisés à se connecter sur certains services de certains serveurs.

Donc au niveau DB, j'ai modélisé ça par trois tables, User, Server, et Service, et une quatrième qui contient des clefs vers un atribut unique de chacune des trois tables précédentes.

Dans le models.py de Django, j'ai écrit ça comme ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
from django.db import models
 
class Server(models.Model):
 
	hostname = models.CharField(max_length=20)
	system = models.CharField(max_length=20)
	server_description = models.CharField(max_length=100)
 
	def __unicode__(self):
		return self.hostname
 
class User(models.Model):
 
	user_name = models.CharField(max_length=20)
	login = models.CharField(max_length=20)
 
	def __unicode__(self):
		return self.user_name
 
class Service(models.Model):
 
	service_name = models.CharField(max_length=20)
	service_description = models.CharField(max_length=20)
 
	def __unicode__(self):
		return self.service_name
 
class Access(models.Model):
 
	service_name = models.ForeignKey(Service)
	hostname = models.ForeignKey(Server)
	user_name = models.ForeignKey(User)

Tout marche impécable
Juste un truc que je ne comprends pas:

Chaque champs de la table Access au niveau MySQL me renvoit les id (indexes primaires des tables auto-increment) des champs correspondants des autres tables.
Par exemple, si j'autorise toto sur le server server_toto et le service service_toto j'aurais le champs toto_id, server_toto_id et service_toto_id dans Access.

Vu la façon dont j'ai implémenté ma classe Access, je m'attendais plutôt à retrouver toto, server_toto, service_toto pour ce champs.

Ce qui me parait un peu bancal? Que se passe-t-il si je cherche à optimiser par exemple la table server? du coup les id se réarangent dans un autre ordre, mais rien n'indique que la table access va être modifiée en conséquence.
Je serais nettement plus à l'aise si Access contenait des vraies caractéristiques de mes objets, et non des id primaires.

Y a-t-il une solution?
Ma question est-elle justifiée? Ou bien aucun souci pour stocker des id primaires pour à terme faire des jointures entre les 3 premières tables?

Merci de vos réponses!

[quinode]

le principe d'un ORM c'est que justement tu ne vas pas mettre les doigts dans le cambouis SQL...

Si les liens se font sur les ID primaires auto-générées, c'est par exemple pour te laisser changer le hostname de tes serveurs sans modifier toutes les tables derrière.

Mais django ne t'empeche pas de le faire :
http://docs.djangoproject.com/en/dev...ary-key-fields

Sinon, avec l'argument "to_field" en definition de ta foreign key tu peux aussi créer des foreignkey sur la base d'un autre champ que l'ID :
http://docs.djangoproject.com/en/dev...gnKey.to_field

mais bon, faut vraiment avoir une raison de faire des choses comme ça pour te compliquer la vie...

Autre chose : j'eviterai d'appeller un model "User" pour eviter tout conflit aléatoire avec le User model de django

[Balbuzard]

Ok, merci beaucoup pour ta réponse.

Si les liens se font sur les ID primaires auto-générées, c'est par exemple pour te laisser changer le hostname de tes serveurs sans modifier toutes les tables derrière.

Je trouvais un peu bizarre de se servir justement de l'id primaire comme clef, je pensais préférable d'en créé un exprès pour ça.

J'avais pas pensé non plus au conflit potentiel entre ma classe User et l'User modèle de Django

Merci encore