Qual è l'approccio migliore per creare uno schema db per il profilo, ma per tenere traccia delle modifiche?

1

Sto lavorando su un sito in cui le aziende possono creare un profilo, quindi aggiungere posizioni per ciascun profilo.

Queste prime due tabelle sono abbastanza semplici.

Tuttavia, eventuali modifiche ai loro profili o posizioni devono passare attraverso un processo di approvazione. Questo è dove sono strappato.

Il risultato finale sarebbe un dipendente che passa attraverso una lista di lavoro e vede le modifiche richieste e fa clic su "approva" o "nega". Approva l'applicazione dei nuovi dati al record esistente, nega l'impostazione di un flag sui record della richiesta e l'invio di una risposta.

Quello che mi chiedo è il modo migliore per fare le richieste di modifica. Vorrei assolutamente mantenere le richieste di modifica in una tabella separata rispetto al profilo o alla tabella di posizione.

Non riesco a decidere se è meglio creare solo duplicati con alcune colonne aggiuntive del profilo e le tabelle di posizione e utilizzare quelle per il rilevamento delle modifiche.

O se dovessi semplicemente creare una semplice tabella con solo le colonne per catturare l'ID, il campo e il valore del target di modifica, oltre a alcuni extra come changeset, datetime, flag, ecc.

Che ne pensi?

    
posta Javalsu 27.08.2013 - 19:44
fonte

1 risposta

2

Dal punto di vista della progettazione del database (ignorando le funzionalità del database e l'architettura dell'applicazione) Preferirò avere una tabella per l'audit trail (cronologia delle modifiche) con modifiche per Entità e per campo implementando una tabella piatta chiamata Trail_History senza chiave esterna a qualsiasi tabella, le colonne saranno:

  1. UserCode : identificatore univoco dell'utente dell'applicazione. (Obbligatorio)
  2. TransactionCode : qualsiasi operazione CRUD dovrà avere un codice transazione univoco (come GUID) (obbligatorio)
  3. ChangeDate : data della transazione. (Obbligatorio)
  4. EntityName : Entità (tabella) che viene manipolata. (obbligatorio)
  5. ObjectId : entità che viene manipolata come chiave primaria.
  6. FieldName : nome del campo di entità.
  7. OldValue : valore vecchio campo Entità.
  8. NewValue : campo Entity nuovo valore
  9. OperationType : discriminatore di operazione CRUD. (Obbligatorio)

L'adozione di questo approccio sarà utile per:

  • Qualsiasi entità (tabella) potrebbe essere tracciata
  • I rapporti saranno leggibili
  • Verranno registrate solo le modifiche
  • Il codice transazione sarà il punto chiave per rilevare le modifiche con una singola azione
risposta data 27.08.2013 - 19:55
fonte

Leggi altre domande sui tag