Best practice: eventi di registrazione (generale) e modifiche (database)

Question

hanno bisogno di aiuto con registrazione di tutte le attività su un sito e modifiche al database.

requisiti:

• dovrebbe essere nel database
• dovrebbe essere facilmente ricercabili da iniziatore (nome utente/ID di sessione), evento (tipo di attività) e l'evento parametri

i può pensare a una progettazione di database ma o coinvolge un sacco di tabelle (una per evento) in modo da poter registrare ciascuno dei parametri di un evento in un campo separato OPPURE coinvolge una tabella con campi generici (7 int numerici e 7 testo tipi) e registrare tutto in una tabella con il campo del tipo di evento che determina quale parametro è stato scritto dove (e sperando che non occorra più di 7 campi di un certo tipo, o 8 o 9 o qualsiasi numero scegliamo) ...

esempio di voci (le solite cose):

[username] login failed @datetime 
[username] login successful @datetime 
[username] changed password @datetime, estimated security of password [low/ok/high/perfect] @datetime 
[username] clicked result [result number] [result id] after searching for [search string] and got [number of results] @datetime 
[username] clicked result [result number] [result id] after searching for [search string] and got [number of results] @datetime 
[username] changed profile name from [old name] to [new name] @datetime 
[username] verified name with [credit card type] credit card @datetime 
datbase table [table name] purged of old entries @datetime via automated process 

ecc ...

così chiunque affrontati prima? qualsiasi migliori pratiche/collegamenti che è possibile condividere?

l'ho visto fare con la soluzione generica di cui sopra, ma in qualche modo va contro ciò che ho imparato dal design del database, ma come puoi vedere il numero di eventi che devono essere tracciabili (ogni utente sarà in grado vedere queste informazioni) mi sta dando mal di testa, ma io amo il primo evento per soluzione da tavolo più di quello generico.

qualche pensiero?

modifica: inoltre, c'è forse un elenco autorevole di tali (probabili) eventi da qualche parte?

thnx

Stack Overflow dice: la questione si sta chiedendo appare soggettiva e rischia di essere chiuso.
la mia risposta: probabilmente è soggettiva, ma è direttamente correlata al mio problema che ho con la progettazione di un database/scrivere il mio codice, quindi sarei felice di ricevere qualsiasi aiuto. inoltre ho provato a restringere le idee a 2, quindi spero che una di queste prevalga, a meno che non ci sia già una soluzione consolidata per questo genere di cose.

Answer 1

1. modifiche database di registrazione per quanto inserti/elimina/aggiornamenti, per quanto riguarda le migliori pratiche vanno, di solito è fatto da un trigger sulle principali voci di scrittura tabella in una tabella di controllo (una tabella di revisione contabile per tabella reale , con colonne identiche + quando/quali/chi colonne).

2. L'elenco di eventi come un elenco generico non esiste. È in realtà una funzione delle tue applicazioni/framework/ambiente/esigenze aziendali.Per quanto riguarda le best practice, è una buona idea decidere se la tua lista di tipi di eventi è al 100% piatta, una gerarchia a 2 livelli (tipo/sottotipo - di solito è l'approccio migliore) o una gerarchia di livello N (molto più difficile/meno efficiente da implementare ma incredibilmente flessibile e offre ottime possibilità per una corretta gestione degli eventi aziendali - Ho partecipato alla realizzazione di tutti e 3 gli schemi, quindi parlo dalla pratica BTW).

3. Non sono necessari 7 campi int generici in 1 tabella per memorizzare i dettagli dell'evento. Invece vanno per la tabella tag-value-pair:

    
   EVENT_TYPES: (event_type, event_subtype, description, subtype_attr1, ...) 
   EVENTS: (event_id, event_type, event_subtype, timestamp, attrib1, ...) 
   EVENT_DETAILS: (event_id, tag, int_value, varchar_value, float_value). 
   

   EVENT_DETAILS possono essere normalizzati in EVENT_DETAILS_INT, EVENT_DETAILS_VARCHAR, EVENT_DETAILS_FLOAT, ... se lo si desidera, ma non realmente necessari.

   attrib1-atttribN nella tabella degli eventi sono attributi generici che si applicano a tutti/la maggior parte degli eventi, come userid, hostname, pid, etc ...

   EVENT_TYPES è una tabella che descrive assortiti tipi di evento/sottotipi.

   A seconda di come è stato deciso il punto 2, questa tabella può memorizzare un elenco di tipi, un elenco di tipi/tipi di sottotipo come nell'esempio o una gerarchia di tipo genitore/figlio (saranno necessarie 2 tabelle per questo, uno per la mappatura genitore/figlio di tipi e uno per gli attributi di tipo di ciascun tipo).

   Si potrebbe desiderare di avere un'altra tabella ausiliaria EVENT_TYPE_ATTRIBUTES che associa i tipi di evento ai tag validi per EVENT_DETAILS.

---

ESEMPIO:

evento: [nome utente] cliccato risultato [numero risultato] [risultato id] dopo la ricerca di [testo da cercare] e ottenuto [numero di risultati] @datetime

questo comporterebbe dati simili a questo (non la sintassi SQL reale, farmi causa :):

 
EVENT_TYPES: (USER_ACTION, USER_CLICK, "User clicked something") 
EVENTS: (12345, "USER_ACTION","USER_CLICK", @datetime, "[username]", 
     "app_name", "pid"...) 
EVENT_DETAILS: several rows: 
(12345, "result_number", 33, NULL, NULL) // Or go into EVENT_DETAILS_INT without NULLs? 
(12345, "result_id", 919292, NULL, NULL) 
(12345, "search_string", NULL, "how do I log events in DB", NULL) 

Answer 2

Hai già dato un'occhiata allo MongoDB? È molto veloce su inserti in quanto non ha alcune funzionalità che i database di relazioni come MySQL hanno, e naturalmente è possibile cercare su qualsiasi campo che hai nei tuoi dati. In realtà la maggior parte delle aziende inizia a usarlo per la registrazione e l'analisi prima di occuparsi di applicazioni più complesse.