Discussion :

[Runther]

Bonjour,
Je fais ce sujet car j'hésite entre deux façons de stocker des données dans l'application que je programme.
En fait mon application va regrouper plusieurs petites applications pour une entreprise. Les utilisateurs seront répartis en groupe, chaque groupe ayant des autorisations pour une ou plusieurs applications.
Ex : le groupe employé à les droits de lecture et modification pour l'appli 1 et de lecture seule pour l'appli 2. Le groupe secrétaire a les mêmes droits + celui de faire un mailing depuis l'appli 1.

Là où j'hésite, c'est :
Premier choix :
Je crée une table GROUPES avec une colonne id_groupe et nom_groupe, puis une colonne par autorisation (donc s'il y a 8 autorisations possibles sur l'appli 1 et 5 pour l'appli 2, ça fera un total de 2+8+5 colonnes).

(Je n'ai pas été très inspiré pour les noms d'autorisation pour cet exemple !).

Deuxième choix :
Je crée une table GROUPES avec une colonne id_groupe et nom_groupe
Je crée une table AUTORISATIONS avec une colonne id_autorisation, appli_autorisation (l'application à laquelle l'autorisation est reliée) et nom_autorisation. Je pré-remplis cette table avec une ligne par autorisation.
Je crée une table GROUPES_AUTORISATION avec une colonne id_groupe et id_autorisation (le tout avec les liaisons étrangères bien entendu). Et lorsque l'utilisateur attribue une autorisation à un groupe, une nouvelle ligne est créée.


Le second choix me paraît plus "propre". Ceci dit, dans la mesure où l'utilisateur ne va pas créer des nouvelles autorisations, que celles-ci n'arrivent que par mise-à-jour, et que donc le nombre d'autorisations est connu, la première me paraît tout à fait valable et nettement plus optimisée (si ce n'est qu'au fur et à mesure du développement, je pourrais me retrouver avec cinquante colonnes, mais ça resterait largement utilisable).
Je sais que les deux solutions fonctionnent, néanmoins, je veux faire le choix le plus propre possible.
Je vous remercie pour votre attention !

[StringBuilder]

Peso, j'aurais fait entre les deux.

Une entité "groupe"
Une entité "application"
Et une relation "autorisations" avec comme attributs "peut_lire, peut_modifier, etc."

Ca me semble plus condensé, même si au final, s'il y a des autorisations spécifiques à une application "peut_paramétrer", "peut_changer_l_age_du_capitaine_mais_pas_celui_du_bateau" tu devras te le coltiner sur les lignes des applications qui n'en ont que faire.

[Runther]

Merci pour ta réponse,
Cependant, la plupart des autorisations seront spécifiques à une seule application (si ce n'est la quasi totalité). Donc je ne suis pas très emballé par cette solution qui au final s'avérerait ressembler à la 1 en un peu plus lourde ^^'
Ceci dit, je te remercie vraiment parce que tu m'as donné un angle de vue auquel je n'avais pas pensé, je vais quand même y réfléchir ^^

[StringBuilder]

Du coup ta seconde solution me semble la plus adaptée.

Si tu veux optimiser au maximum, tu peux aussi partir sur un système de flags (à la condition que tu n'en aies pas besoin dans les requêtes SQL).


Toujours le système que j'avais proposé, avec une seule colonne pour les droits "rights" de type tinyint, smallint, int ou bigint selon le nombre de droits par application, et les droits stockés en binaire (à l'aide d'un masque binaire).
L'avantage c'est que tu n'utilise qu'un minimum de place pour gérer les droits, et la relecture est ultra optimisée (une seule ligne à lire pour déduire jusqu'à 64 droits différents pour une application).

Le revers, c'est qu'il faudra hardcoder dans l'application client à quoi correspond chaque bit pour chaque application.
Et au niveau des requêtes/index ça va vite être usine à gaz si tu veux retrouver par exemple la liste de tous les utilisateurs qui ont le droit de modifier des données dans l'application A mais pas dans l'application B par exemple.

[Runther]

Merci bien pour tes réponses !
Du coup je vais probablement me tourner vers la solution 2.
La solution binaire est tentante mais je la sens vraiment mal (pour les raisons que tu cites ^^).
Merci beaucoup !

[aieeeuuuuu]

Bonjour,

Pour ma part, de façon générale, je ne vois pas l’intérêt d'utiliser un masque de BIT, par rapport à utiliser N colonnes de type BIT (si ce n'est de pouvoir prendre en charge de nouveaux droits sans modifier le modèle).

Et de façon générale aussi, la solution 2 est effectivement à mettre en œuvre, en ajoutant une table des applications plutôt qu'un nom d'application directement dans la table autorisation

[Runther]

Alors figure-toi que je viens de revoir mon plan et effectivement, j'ai déjà fait ce dont tu parles (la table applications). J'avoue me sentir vraiment bête de pas y avoir pensé directement ^^

[escartefigue]

Bonjour,

Pour ma part, je proposerais un modèle comme suit

UTILISATEUR 0,n --- appartenir --- 0,n GROUPE
GROUPE 0,n --- autoriser --- 0,n ACTION
ACTION (1,1) --- concerner --- 0,n APPLICATION

Ce qui donne les tables suivantes, avec une gestion des relations à date
UTILISATEUR (UT_id, UT_nom, UT_prenom...)
GROUPE (GR_id, GR_nom...)
APPARTENIR (UT_id, GR_id, AP_DTDEB, AP_DTFIN) relation à date entre utilisateur et groupe
APPLICATION(AP_id, AP_nom...)
ACTION(AP_id, AC_id, AC_libelle) l'action est identifiée relativement à l'application (d'où les parenthèses sur les cardinalités), la PK de ACTION est donc composée en majeur de la PK de l'application + l'identifiant de l'action
AUTORISER (GR_id, AP_id, AC_id, AU_DTDEB, AU_DTFIN) autorisation à date d'un groupe pour une action