Procedura o creazione dell'attività per riempire il database di sistema con dati di sistema non generati dall'utente

0

Contesto

Voglio progettare una procedura o un'attività di sistema da caricare in un database, i dati che sono necessari al sistema per funzionare. L'esempio più semplice che riesco a trovare è un ACL (o RBAC, non sicuro quale sia il termine corretto) in cui un utente ha bisogno di autorizzazione per eseguire determinate azioni (creare una risorsa, visualizzare una risorsa, visualizzare un elenco con scope, visualizzare un globale lista).

In questo esempio, come schema di base avremmo un modello di relazione user N:M role N:M permission .

La tabella permission contiene una colonna (diciamo name ) con un valore che verrà utilizzato dal sistema per determinare l'autorizzazione necessaria per eseguire questa azione:

if loggedUser.can('reports.view.global')
  reports = reportsRepo.all()
else
  reports = reportsRepo.allForDepartment(loggedUser.department)
end

Poiché il sistema dipende da questi valori "hard coded", devono essere sincronizzati con il database su ciascuna distribuzione. Ciò significa che se la prossima versione aggiungerà 2 nuove funzionalità (con 2 nuove autorizzazioni) ed eliminerà 1 funzione (con 1 autorizzazione), l'attività di distribuzione dovrebbe aggiornare il database per mantenerlo sincronizzato con le autorizzazioni con cui funzionerà la prossima versione.

Domande

Avendo spiegato ciò, voglio anche prendere in considerazione che non sto cadendo sotto XY Problem e questo è in realtà l'approccio corretto per questo problema:

  1. Questo tipo di dati di sistema (non è sicuro se il concetto stesso ha un nome) può essere memorizzato in un database (a scopi di query-abilità) o esiste un modo standard migliore?
  2. È un approccio cli che verifica i valori dei dati di sistema (in alcuni file di configurazione) e li sincronizza con la tabella permission (aggiunta o eliminazione di righe) un buon approccio, o non è dovuto a qualche motivo che sono non riescono a vedere al momento?

Non ho mai visto un'implementazione di questo scenario comune prima, quindi mi chiedo se c'è già un approccio standard per questo particolare problema (forse è anche chiamato e devo solo google ma non so che è nome ...)?

    
posta Christopher Francisco 08.06.2017 - 02:43
fonte

1 risposta

1
  1. Should these kind of system data (not sure if the concept itself has a name) be stored in a database (for query-ability purposes) or is there a better standard way?

Sì, archiviarlo nel database è una scelta ragionevole di design.

  1. Is a cli task that checks for those system data values (in some config file) and sync them with the permission table (adding or deleting rows) a good approach, or is it not due to some reason I'm failing to see at the moment?

Sì, l'attività di aggiornamento del database è il posto giusto per l'aggiornamento dei dati.

Se hai zero requisiti di tempo di inattività, ti suggerirei di aggiungere un numero di versione o un conteggio per nominare la tabella delle autorizzazioni al ruolo in modo che due o più tabelle di autorizzazioni possano essere entrambe presenti nel database allo stesso tempo tempo.

Quindi, aggiungi una nuova tabella delle autorizzazioni a conoscenza solo della nuova applicazione. Questa tabella non danneggerà la vecchia applicazione, poiché non è stata modificata nulla. Il nuovo aggiornamento conosce (e utilizza solo) la nuova tabella dei permessi, quindi puoi passare a essa o eseguirli entrambi affiancati.

Le alternative stanno aggiungendo un numero di versione / colonna di conteggio alla tabella dei permessi, ma penso che sarebbe più complicato.

Un'altra alternativa è, se non dinamica, mantenere le informazioni relative al ruolo nel codice stesso.

    
risposta data 08.06.2017 - 03:15
fonte

Leggi altre domande sui tag