Discussion :

[eponyme]

Bonjour à tous.
Je viens vers vous pour une question de construction de BDD pour un portail Intranet, avec gestions d'utilisateurs et d'applications. Mon problème se situe dans la façon de gérer "génériquement" les applications et leurs paramètres propres. Je commence d'abord par l'idée des tables que j'ai :
service : id,libellé,diminutif,couleur
utilisateur : login,password,nom,prenom, ....
application : id,nom,URL,is_public
acces : login,id_application,droit

Donc en gros j'ai la table "acces" mer permettant de savoir si tel login à accès à l'application (droit peut etre un boolean, ou un entier pour avoir plusieurs niveaux de droits, je ne sais pas encore).
Mon problème est que j'ai une application, pour laquelle certains utilisateurs de cette base seront administrateurs. Une autre application pour laquelle d'autres utilisateurs seront administrateurs. On peut imaginer que j'aurais d'autres applications, pour laquelle j'aurais besoins de stocker des informations concernant les utilisateurs, mais propres à l'application (droits, couleur associée,personnalisation de présentation, etc ...).
Ma question est de savoir ou je doit stocket ces infos
- Dans la base de chaque application ? : Dans ce cas la a chaque fois qu'une application le nécessitera, je devrais gérer un complément de base utilisateurs pour rajouter des information, à chaque fois que je crérais un nouvel utilisateur pour le portail, je devrais aller dans chaque application le créer aussi pour personnaliser ses infos, etc...
- Dans la base du portail intranet (citée plus haut), auquel cas ... comment faire pour avoir des tables prenant en charge des parametres de types différents selon l'application ?

Bref, comment contruire un portail avec une gestion d'utilisateurs intelligente, et dont les applications peuvent avoir des informations concernant des utilisateurs sans pour autant recréer des tables ?

Merci d'avance

eponyme

[_skip]

Peut-être que tu devrais limiter ta table accès à indiquer qu'un utilisateur a droit ou non d'utiliser une certaine application mais sans spécifier le niveau de droit exact. Ca te permet de rapidement savoir qui peut aller ou sans entrer dans les détails.

- Dans la base du portail intranet (citée plus haut), auquel cas ... comment faire pour avoir des tables prenant en charge des parametres de types différents selon l'application ?

Je te recommande pas trop cette méthode car depuis ton application il faudra sans arret jongler entre les bases, et de plus ça risque de poser des problèmes de maintenance de mixer du spécifique avec du global.
Je pense que c'est plus simple de garder ces informations de profil au niveau de la base de l'application car comme tu l'as mentionné ils sont propres à l'application.

De plus il est peut être possible qu'une application nécessite des paramètres qui lui sont spécifiques. Alors si tu devais choisir cette méthode malgré tout, tu pourrais gérer ces spécificités avec une table du genre :

login, id_app, key, value

Ou key est le nom du paramètre et value la valeur
exemple

Code :

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

1
2
3
4
key                             value
--------------------------------------------
"PARAM_COLOR"              "#00FF00"
"PARAM_FONT                 "arial"

Une classe de manipulation avec des méthodes style
GetParamColor()
SetParamColor()
GetParamFont()
....

et le tour est joué, c'est très gérable et relativement élégant.

- Dans la base de chaque application ? : Dans ce cas la a chaque fois qu'une application le nécessitera, je devrais gérer un complément de base utilisateurs pour rajouter des information, à chaque fois que je crérais un nouvel utilisateur pour le portail, je devrais aller dans chaque application le créer aussi pour personnaliser ses infos, etc...

Si tu veux une copie-conforme de cette table utilisateur dans les autres bases, il est certainement possible de créer une procédure stockée couplée avec un trigger sur INSERT/UPDATE qui répercute les modifications faites dans la base globale sur les bases enfants.
En fait tu n'as pas besoin que de la clef primaire de l'utilisateur quelque part en mémoire, pas des informations nom-prenom qui sont accessibles sur la base globales?

[eponyme]

Merci pour ces indications.
Je dois y réfléchir plus en détail, mais le principe de key/value me plait assez.
Merci du conseil

[eponyme]

J'ai finalement retenu la solution des key/value,
ca donne ca :
SERVICE : id_service,lebelle_service,...
UTILISATEUR : login,nom,prenom,mail,...
APPLICATION : id_application,nom,url,...
ACCES : login,id_application,droit
PARAMETRE : login,id_application,key,value

Cela ne posera pas trop de souci de jonglements entre les bases car lors de la connexion à une application, je récupererai les parametres propres à l'utilisateur dans la table PARAMETRE et les stockerai dans la session.

Merci pour le coup de main

eponyme