MySQL - Struttura per le autorizzazioni agli oggetti

Question

Quale sarebbe una struttura ideale per gli utenti> permessi di oggetti.

Ho visto molti post correlati per le autorizzazioni generali, o quello che le sezioni di un accesso utente può, che consiste in un users, userGroups e userGroupRelations o qualcosa del genere.

Nel mio sistema ci sono molti oggetti diversi che possono ottenere creati, e ognuno deve poter essere acceso o spento. Per esempio, prendete un gestore di password che ha gruppi e sottogruppi.

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

Ogni gruppo può contenere una serie di password. Un utente può essere dato in lettura, scrittura, modifica e cancellazione delle autorizzazioni a qualsiasi gruppo. Più gruppi possono ottenere creati in qualsiasi punto nel tempo.

Se qualcuno ha il permesso di un gruppo, dovrei essere in grado di fargli avere le autorizzazioni a tutti i gruppi secondari o limitare a solo quel gruppo.

Il mio pensiero attuale è quello di avere un tavolo gli utenti, e quindi una tabella di autorizzazioni con le colonne come:

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)

Questo ha funzionato in passato, ma il nuovo sistema Sto costruendo ha bisogno di essere in grado di scalare rapidamente, e non sono sicuro se questa è la migliore struttura. E 'anche l'idea di avere qualcuno con tutti i permessi sottogruppo di un gruppo più difficile.

Ci sarà un tavolo separato per i ruoli degli utenti / amministratori, che significa che possono cambiare i permessi sugli utenti sotto i gruppi che possono controllare.

Quindi, come una domanda, devo usare la struttura di cui sopra? O Qualcuno mi può punto nella direzione di uno migliore?

---

Modifica

alternativa è quella di creare una tabella di autorizzazione per ogni tipo di oggetto.

Answer 1

Vi suggerisco di aggiungere un timestamp "last_update" e una colonna "last_updated_by_user" in modo da avere qualche speranza di tracciare modifiche a questa tabella nel vostro sistema in esecuzione.

Si potrebbe considerare l'aggiunta di un permesso - sovvenzione. Un utente che abbia il permesso di sovvenzione per un oggetto sarebbe in grado di concedere l'accesso ad altri utenti per l'oggetto in questione.

Fare attenzione con "esigenze di scalare rapidamente." E 'difficile immaginare, senza esperienza di produzione del mondo reale ciò che un sistema in scala-up ha davvero bisogno.

Inoltre, fare attenzione a non a un eccesso di complicare un sistema di autorizzazioni, a causa di un sistema eccessivamente complesso sarà difficile da verificare e quindi più facile da decifrare. Un sistema semplice sarà molto più facile per refactoring per scale-up di una più complessa.

Il tuo schema sembra riferirsi utenti agli oggetti. Volete che il vostro chiave primaria e l'indice unico da (user_id, object_id)? Cioè, vuoi ciascun utente di avere zero o uno il permesso di entrata per ogni oggetto? In tal caso, utilizzare la chiave primaria per far rispettare che, invece di usare il surrogato chiave si propone permission_id.

Per i vostri oggetti che esistono nelle gerarchie, si dovrebbe fare una delle due scelte a livello di sistema:

1. una borsa di studio ad un oggetto con sottoggetti concede implicitamente l'accesso solo al oggetto, o ...

2. concede anche l'accesso a tutti gli oggetti secondari.

La seconda scelta riduce l'onere di autorizzazione esplicita concessione quando vengono creati nuovi oggetti secondari. La prima scelta è più sicura.

La seconda scelta rende più difficile per determinare se un utente ha accesso a un oggetto particolare, perché si deve percorrere la gerarchia di oggetti verso la radice dell'albero alla ricerca di borse di studio di accesso su oggetti padre quando verificare se un utente ha accesso. Questo problema di prestazioni dovrebbe dominare il processo decisionale. Saranno gli utenti di creare un paio di oggetti e accedervi spesso? O saranno creare molti oggetti e suboggetti e accedervi raramente? Se l'accesso è più frequente di quanto creazione, si desidera che la prima scelta. Prendere il colpo in testa il permesso di concessione al momento della creazione di oggetti, piuttosto che un colpo permesso-ricerca al momento l'accesso agli oggetti.

Penso che la prima scelta è probabilmente superiore. Suggerisco questo layout tabella:

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.

Si potrebbe anche usare questo layout del tavolo, e hanno una riga nella tabella per ogni autorizzazione concessa distinti per ogni utente per ogni oggetto. Questo uno scale up più facilmente se si aggiungono altri tipi di autorizzazioni.

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