Considera la seguente struttura della tabella, per il back-end di un sito web:
[Article]
ArticleId
Text
TotalViews
AuditModifiedOn
AuditModifiedByUserId
[User]
UserId
Un utente anonimo / non autenticato visita un articolo e questo fa aumentare il contatore TotalViews. Cosa dovrebbe diventare AuditModifiedByUserId quando si aggiorna il record?
L'utente visualizzazione non modifica il documento, quindi non mi aspetto che tu lo aggiorni.
Dal tuo commento sopra, mi aspetto che l'utente modifichi il documento da autenticare, e questo è il record dell'utente con cui modificare la voce del documento. Se è stato modificato da un'operazione di pianificazione automatica (ad esempio), è possibile che si desideri un utente SYSTEM o simile, ma in caso contrario si suppone che si debba ottenere un utente autenticato dalla richiesta Web.
Sicuramente non penso che una colonna di audit debba essere NULLable.
Guardando questo, sembra che la modellazione non sia corretta. Ti suggerirei forse che hai bisogno di una tabella che rappresenti il documento, la versione, le informazioni di controllo ecc. E una tabella separata che memorizza le informazioni di visualizzazione (con una chiave esterna che collega alla tabella del documento).
Ci sono diversi modi per gestire la tua verifica. La maggior parte dei siti Web professionali considera che un utente non ha registrato le persone che le rintracciano con i cookie. Quindi la tua tabella potrebbe essere (Questo è un esempio molto semplificato):
[User]
UserId
SessionId
Registered
Dove registrato è un valore booleano. Amazon e molti grandi siti web tracciano le tue azioni quando non sei registrato con i cookie; quindi quando si registra associa una mail e un nome utente (e altre informazioni inserite nel modulo di registrazione) con le azioni precedenti, generando un profilo più completo anche prima della registrazione.
Quindi all'inizio puoi identificare un utente con i cookie memorizzati nella colonna SessionId e infine, se l'utente lo registra, identificarlo con un nome utente.
Nella mia esperienza, la colonna utente è solitamente compilata con un account "sistema" o qualche altro indicatore che l'aggiornamento è stato eseguito automaticamente piuttosto che da una richiesta esplicita dell'utente. Sono d'accordo con gli altri, però, che questa particolare parte del design del database dovrebbe essere refactored. Suggerirei una tabella separata contenente l'ID dell'articolo, un timestamp (quando l'articolo è stato letto) e un ID utente. Se necessario, puoi creare una vista che imita lo schema corrente, con la colonna TotalViews come la somma del conteggio dell'articolo letto.