I record di audit dovrebbero avere il proprio ID?

Question

I record di audit dovrebbero avere il proprio ID?

#1 da (-1 voti)
#2 da (-1 voti)

2

Sto creando tabelle di controllo per tenere traccia delle modifiche apportate ad alcune delle mie tabelle cruciali e mi chiedo se ci sia un punto in cui le righe della cronologia hanno il loro id. Ecco come appaiono le mie interfacce:

public interface ITrackedDbEntity : IDbEntity
{
    Guid GUID { get; } //pk, unique
    int Id { get; set; } //unique, not pk

    string CreatedBy { get; set; }
    DateTime CreatedAt { get; set; }
    string LastModifiedBy { get; set; }
    DateTime LastModifiedAt { get; set; }
}
public interface IHistoryDbEntity : ITrackedDbEntity
{
    string ActionType { get; set; }
}

GUID è l'identificatore univoco e immutabile attuale e viene utilizzato internamente nel mio sistema, mentre Id è una sorta di identificatore aggiuntivo che posso modificare se necessario e condividere in sicurezza all'esterno (ho anche un relazione di chiave estera dalla tabella di controllo ad essa). Ora, come per la chiave primaria della tabella di controllo, ho pensato che una chiave composta di Id e LastModifiedAt sarebbe sufficiente. Ciò mi consentirebbe persino di creare una relazione di chiave esterna tra guida tabella principale e guida tabella di controllo per una più semplice esecuzione di query.
Ma cosa mi sto chiedendo e qual è la mia domanda: c'è qualche motivo valido per creare un AuditId unico per le tabelle di controllo?

database architecture audit

posta Amai 15.04.2018 - 12:11

fonte

2 risposte

Leggi altre domande sui tag database architecture audit

che introduce i puntatori a un grande progetto software L'API RESTFUL è il servizio back-end una delle migliori (o idonee) scelte per l'app mobile? [chiuso]

score -1 · Answer 1

Mi aspetto che una tabella di controllo assomigli a questa:

Audit
   id - guid
   actionTakenOnObjectId - guid, possibly fk to object table
   typeOfObjectActionTakenOn - possibly have this if you are sharing the audit table with multiple other tables.
   actionType
   actionDate - UTCDateTime
   actionData - string data associated with the change. ie first name from x to y
   userId - guid, Id of the user that took the action

La cosa fondamentale con la tabella di controllo è che si è sempre in grado di aggiungere voci. Con questo design il GUID PK significa che non otterrai mai un record duplicato e puoi inserire record da più computer e thread a tuo piacimento.

Inoltre, puoi registrare cose come: utente x record visto y, in cui non avviene alcun cambiamento di dati.

Nella tua situazione hai un paio di cose strane.

l'int extra int col. Non sono sicuro di quali siano le tue ragioni per questo e tu dici che può cambiare. Lasciamo fuori dall'equazione per ora
Stai facendo un duplicato esatto della riga esistente invece di memorizzare solo un sottoinsieme di informazioni sull'evento.

Normalmente direi che una colonna datetime non ha una risoluzione sufficiente per essere una chiave primaria. È possibile che si verifichino due eventi contemporaneamente e il secondo non verrà inserito per la presenza di una chiave duplicata.

Tuttavia, nel tuo caso, poiché l'audit è direttamente correlato a una modifica della riga del database, sarebbe possibile incapsulare l'aggiornamento e l'inserto di revisione nella stessa transazione. Aggiunta di un segno di spunta su LastUpdatedDate in cui si rileva che non è stato modificato dall'ultimo aggiornamento.

Supponendo di utilizzare il GUID invariato, anziché l'int id modificabile, sarebbe quindi possibile garantire che l'ora sia sempre univoca e che sia sempre possibile inserire un record di controllo.

Se tuttavia segui questo approccio, potresti essere meglio utilizzato aggiungendo invece una colonna LastVersion - guid che fa esplicitamente riferimento al precedente record di controllo per la riga.

Nel complesso, si tratta di un approccio complesso, simile a Event Sourcing. e si basa sull'imposizione dell'ordine di eventi di modifica dell'oggetto. Se ottieni due modifiche alla stessa versione dell'oggetto. ad esempio aggiorno il nome, mentre un altro utente aggiorna l'indirizzo. Quindi potresti voler rifiutare la seconda modifica con un messaggio di stile "Un altro utente ha cambiato l'oggetto mentre stavi modificando".

Ovviamente ogni caso è diverso, ma, in generale, vorrei consigliare per usando un nuovo PK su una tabella di controllo e contro avendo una tabella di controllo che suppongo è un tipo di registro delle transazioni per un'altra tabella.

score -1 · Answer 2

Non aggiungerei un riferimento / ID univoco a una tabella di controllo di un'altra tabella. Se la tua tabella di controllo sta verificando qualche altro processo che potrebbe coinvolgere dati provenienti da più tabelle, si tratta di una storia diversa.

Se ci fosse un motivo per rendere più facile l'identificazione di un record specifico per la modifica dei dati, eviterei le chiavi composte. Le chiavi composte rendono i join più complicati, ma raramente è necessario farlo con una tabella di controllo.

Le tabelle di controllo sono un motivo accettabile per avere una chiave composta. Normalmente, sono contro di loro.