MySQL - Structure pour les autorisations d'objets

Question

Quelle serait une structure idéale pour les utilisateurs> autorisations d'objets.

Je l'ai vu de nombreux postes connexes pour les autorisations générales ou quelles sections un accès de boîte utilisateur, qui consiste en un users, userGroups et userGroupRelations ou quelque chose de cette nature.

Dans mon système, il y a beaucoup d'objets différents qui peuvent se créer, et chacun doit pouvoir être activé ou désactivé. Par exemple, prenez un gestionnaire de mot de passe qui a des groupes et des sous-groupes.

Group 1
    Group 2
    Group 3
    Group 4
Group 5
   Group 6
Group 7
   Group 8
       Group 9
       Group 10

Chaque groupe peut contenir un ensemble de mots de passe. Un utilisateur peut être donné lecture, écriture, éditer et autorisations de suppression à tout groupe. Plus de groupes peuvent se créer à tout moment.

Si quelqu'un a la permission à un groupe, je devrais être en mesure de lui faire disposer des autorisations à tous les sous-groupes ou de limiter à tout ce groupe.

Ma pensée actuelle est d'avoir une table d'utilisateurs, puis une table d'autorisations avec des colonnes comme:

permission_id (int) PRIMARY_KEY
user_id (int) INDEX
object_id (int) INDEX
type (varchar) INDEX
admin (bool)
read (bool)
write (bool)
edit (bool)
delete (bool)

Cela a fonctionné dans le passé, mais le nouveau système que je suis bâtiment doit être en mesure d'évoluer rapidement, et je ne suis pas sûr si cela est la meilleure structure. Il fait aussi l'idée d'avoir quelqu'un avec toutes les autorisations de sous-groupe d'un groupe plus difficile.

Il y aura une table séparée pour les rôles des utilisateurs / administrateurs, ce qui signifie qu'ils peuvent changer les autorisations sur les utilisateurs ci-dessous les groupes qu'ils peuvent contrôler.

Alors, comme une question, dois-je utiliser la structure ci-dessus? Ou peut pointer quelqu'un me dans le sens d'une meilleure?

---

EDIT

Alternative est de créer une table d'autorisation pour chaque type d'objet.

Answer 1

Je vous suggère d'ajouter un horodatage « last_update » et une colonne « last_updated_by_user » si vous avez un peu d'espoir de suivre les changements à cette table dans votre système en cours d'exécution.

Vous pourriez envisager d'ajouter une autorisation - subvention. Un utilisateur ayant l'autorisation d'attribution d'un objet serait en mesure d'accorder l'accès à d'autres utilisateurs à l'objet en question.

Soyez prudent avec les « besoins à l'échelle rapidement. » Il est difficile de deviner sans expérience de production dans le monde réel ce qu'est un système à l'échelle-up a vraiment besoin.

En outre, veillez à ne pas trop compliquer un système d'autorisations, car un système trop complexe sera difficile de vérifier et donc plus facile à se fissurer. Un système simple sera beaucoup plus facile de refactoring pour que un mise à l'échelle plus complexe.

Votre schéma semble relier les utilisateurs à des objets. Voulez-vous votre clé primaire et votre index unique d'être (user_id, object_id)? C'est, voulez-vous que chaque utilisateur ait zéro ou une entrée autorisation pour chaque objet? Dans ce cas, utilisez la clé primaire pour faire respecter que, plutôt que d'utiliser la mère porteuse permission_id clé que vous proposez.

Pour vos objets qui existent dans les hiérarchies, vous devez faire l'un des deux choix Systemwide:

1. une subvention à un objet avec des sous-objets accorde implicitement l'accès à la seule objet, ou ...

2. il accorde également un accès à tous les sous-objets.

Le second choix réduit le fardeau de la permission explicite accorder lorsque de nouveaux sous-objets sont créés. Le premier choix est plus sûr.

Le second choix rend plus difficile de déterminer si un utilisateur a accès à un objet particulier, parce que vous devez marcher sur la hiérarchie des objets vers la racine de l'arbre à la recherche de subventions d'accès sur les objets parents lors de la vérification si un utilisateur a accès. Ce problème de performance devrait dominer votre prise de décision. Est-ce que vos utilisateurs de créer quelques objets et accès qui leur est souvent? Ou vont-ils créer de nombreux objets et sous-objets et les accès rarement? Si l'accès est plus fréquente que la création, vous voulez que le premier choix. Prenez l'autorisation d'octroi de coup en tête au moment de la création d'un objet, plutôt que d'un coup de permission de recherche au moment de l'accès aux objets.

Je pense que le premier choix est probablement supérieur. Je suggère cette disposition de la table:

user_id (int)
object_id (int)
type (varchar)  (not sure what you have this column for)
admin (bool)
read (bool)
write (bool)
edit (bool)
grant (bool)
delete (bool)
last_update (timestamp)
last_updated_by_user_id (int)
primary key = user_id, object_id.

Vous pouvez également utiliser cette disposition de la table, et une ligne de la table pour chaque autorisation distincte accordée à chaque utilisateur pour chaque objet. Celui-échelles plus facilement si vous ajoutez plusieurs types d'autorisations.

user_id (int)
object_id (int)
permission_enum (admin/read/write/edit/grant/delete)
type (varchar)  (not sure what you have this column for)
last_update (timestamp)
last_updated_by_user_id (int)
primary key = user_id, object_id, permission_enum