Ledger o log design per un sistema basato su punti?

6

In questo momento stiamo creando un nuovo servizio che si integrerà nella piattaforma esistente della nostra azienda. Il servizio sarà responsabile del monitoraggio dei "punti" che un utente può generare nel tempo attraverso determinate attività.

Sono preso tra due diversi metodi di approccio. Non sono sicuro se scegliere una delle seguenti strutture per gestire continuamente i punti:

  1. Crea un "log" di punti e mantieni invece un totale parziale nel database, come un campo chiave / valore, in cui il valore è il saldo punti attuale che viene semplicemente regolato durante ogni transazione.
  2. Crea un sistema "ledger" in cui ogni volta che i punti vengono ricalcolati dopo una determinata condizione, ma il intero libro mastro viene valutato per determinare il saldo dei punti più aggiornato.

Non pensare che sia rilevante, ma il DB di back-end è Riak.

Quale ha il minimo inconveniente, o c'è un modo migliore? Come funziona il sistema di punti StackExchange in relazione a quanto sopra? Mille grazie per l'input!

    
posta crockpotveggies 26.02.2013 - 23:53
fonte

1 risposta

1

Questa non è una o / o materia.

Una cosa che è piuttosto comune nei sistemi di contabilità è implementare un sistema basato su log, ma uno con i "saldi di chiusura" storici elencati periodicamente, spesso in un'altra tabella. I saldi di chiusura possono quindi servire da punto di roll-forward in un rapporto. I vantaggi di tale approccio sono:

  1. È possibile eliminare i vecchi dati se è necessario dopo x anni.

  2. I tuoi report non devono aggregare più di una quantità di dati dall'ultima finestra di manutenzione dei dati chiusa e i vecchi dati ora sono di sola lettura).

In un RDBMS (non così sicuro su Riak), si dovrebbe anche avere una logica per impedire che i record più vecchi vengano inseriti prima dei punti di rollforward.

    
risposta data 27.02.2013 - 04:42
fonte