Il modo migliore per tenere traccia delle modifiche dell'utente

Naviga le tue risposte
0

Sto sviluppando una webapp con utenti e ruoli e devo tenere traccia di tutte le modifiche apportate, in modo da sapere quando e chi ha cambiato un ruolo utente.

Ho la mia tabella utente: 

CREATE TABLE user(
       user_id, 
       name
);

E la mia tabella user_role (un utente può avere molti ruoli): 

CREATE TABLE user_role(
           user_id,
           role_id
   );

Ho 2 potenziali approcci per gestirlo:

  1. Aggiungi alcuni attributi alla tabella user_role , quindi sarebbe qualcosa di simile a 

    CREATE TABLE user_role(
       user_id,
       role_id,
       change_date,
       changed_by,
       .....
);

    Con questo approccio, ogni volta che viene modificato un ruolo utente, viene creata una nuova voce.

  2. Avere una nuova tabella: 

    CREATE TABLE user_role_historic(
    user_id,
    role_id,
    change_date,
    changed_by
    ....
);

So che (penso) entrambi gli approcci potrebbero funzionare, ma non riesco a decidere quale sia il migliore. Qualcuno può aiutarmi?

    
posta Manu 19.08.2017 - 09:34
fonte

4 risposte

2

Vorrei andare con il secondo se lo fai in questo modo; le idee "user" e "user change history" sono due cose diverse. Semplificherebbe la differenziazione tra le azioni "controlla quali ruoli ha un utente" e "verifica quando un ruolo utente è stato modificato e da chi."

    
risposta data 19.08.2017 - 09:42
fonte
0

In generale, dipende da come si desidera accedere ai dati. In questo caso particolare, penso che guardi i dati in due modi diversi. Uno qual è il ruolo attuale e qual è stato il ruolo dell'utente in questo momento e le query vengono utilizzate in diversi modi, ad es. l'autorizzazione di sicurezza guarda sempre quella corrente mentre la cronologia è un rapporto separato.

Mantenere i dati in una tabella è utile se ogni query utilizza un tempo, ovvero la query mi restituisce sempre i dati in questo momento. Per un uso più dettagliato consultare i database temporali, ad es. la risposta qui

    
risposta data 23.08.2017 - 13:05
fonte
0

L'esempio fornito dal tuo secondo approccio sembra sbagliato: solitamente i campi come change_by e changed_date si trovano nella tabella principale. E la storia dei cambiamenti è in un'altra tabella dedicata.

Questo perché potrebbe essere necessario conoscere l'ultima data di modifica senza toccare la tabella della cronologia (che si desidera evitare quando non è necessario).

Nota anche che c'è un modulo di ibernazione per fare le cose per te: link

    
risposta data 23.08.2017 - 13:21
fonte
-1

La soluzione 2 è migliore, poiché la cronologia viene archiviata indipendentemente dalla tabella controllata, quindi viene mantenuta anche se il record originale viene eliminato. Tuttavia, sarebbe anche meglio espanderlo per coprire anche inserti ed eliminazioni. Quindi aggiungi un campo azione per indicare Inserisci, Aggiorna, Elimina:

CREATE TABLE user_role_history (     ID utente,     ROLE_ID,     cambia data,     changed_by,     azione     .... );

    
risposta data 21.08.2017 - 12:57
fonte

Leggi altre domande sui tag

È possibile spedire librerie con codice? Autorizzazione remota per ogni richiesta di risorsa REST