Gestione dei dati modificati retroattivamente riportati gerarchicamente

Quando si dispone di report dipendenti dal tempo, che dipendono in modo significativo da altri dati dipendenti dal tempo come "quando ha fatto un membro del team a un team", è necessario tenere traccia della cronologia di tutti i record rilevanti se si desidera ottenere il riferisce giusto. E, naturalmente, quando si esegue il report, è necessario indicare al sistema la data in cui si desidera il report, quindi se si esegue il report il 10 aprile, ma si desidera un report ancora per il 31/03, si otterrà esattamente che.

Quindi, nel tuo esempio, potresti avere tre tabelle "Persona", "Squadra" e "Abbonamento", in cui l'appartenenza deve contenere gli attributi dell'intervallo di date. In questo approccio, non vi è alcuna denormalizzazione. Con questo modello, dovrebbe essere semplice includere la data specificata per la quale il report è stato richiesto nella query.

Sembra che tu creda che questo abbia qualcosa a che fare con il modello di gerarchia organizzativa - probabilmente è solo un equivoco, perché quella parte del tuo modello attualmente non traccia correttamente la storia. Lo stesso problema si presenterebbe con qualsiasi altro tipo di dati, se mancavano i campi appropriati di data / ora.

Per alcuni tipi di sistemi va bene evitare la modellazione esplicita delle date, perché ogni mese o trimestre si effettua un blocco completo dei dati, si imposta una nuova copia del database e si eseguono report contro la versione congelata di il db. Ma in generale questo approccio spesso non è adatto, dal momento che hai bisogno di una granularità più fine o non vuoi assumerti l'onere di occuparti di queste copie di database freezed.

Se ti trovi in una situazione in cui non puoi modificare facilmente il modello dei dati di base (forse il tuo CRM è un prodotto di terze parti, come hai detto), invece di congelare il db nel suo insieme, potrebbe essere più adatto snapshot automatico di tutti i dati rilevanti nel database ad alcune tabelle aggiuntive alla fine di ogni mese ed esecuzione dei report su questa istantanea. Queste tabelle potrebbero far parte del "db aziendale", magari in uno schema separato "al mese", oppure potrebbero risiedere in un "database di report" speciale e leggero. Anche i parametri di controllo che potrebbero essere modificati in seguito per "motivi di lavoro" devono essere inclusi nell'istantanea, ma è necessario offrire una funzionalità per regolarli successivamente senza modificare i "dati principali".

La separazione dei report dall'elaborazione OLTP standard può avere alcuni vantaggi aggiuntivi in termini di prestazioni e disponibilità, specialmente se si tratta di un sistema "grande".

Una soluzione è quella di segnalare "eventi" a volte chiamati eventi di dominio.

Invece di selezionare da un database relazionale e assicurarti che esso modellino correttamente la cronologia, scrivi i tuoi eventi di vendita su una tabella piatta mentre si verificano ed esegui il report fuori da tale tabella.

Quindi se gli eventi devono essere corretti, dì che sono stati registrati contro la squadra X quando in realtà avrebbero dovuto essere assegnati alla squadra Y, puoi facilmente modificare i dati dell'evento ed eseguire nuovamente il rapporto.

Puoi ovviamente generare i dati dopo il fatto piuttosto che registrarlo come accade, anche se questo può portare a punti di strozzatura quando devi generare grandi quantità di dati.

Guarda in "Pattern / architettura di sourcing per eventi". Anziché memorizzare gli stati degli oggetti, stai registrando un flusso di eventi, che può essere utilizzato per ricreare lo stato dell'oggetto.

Ora puoi inserire l'evento personalizzato di un membro che modifica i team dopo il fatto e rigenerare gli oggetti in base a questo flusso di eventi modificato.

L'utilizzo di istantanee può aiutare con le prestazioni quando si hanno a che fare con molti eventi.