Event sourcing vs tabelle temporali di SQL Server

1

Con la creazione di Tabelle temporali in SQL Server 2016 ( o tecnologie simili in altri database), consideri Event Sourcing non necessario?

Entrambe sono tecniche di controllo, molto simili (una riguarda le entità, l'altra con DTO specializzati), ma le tabelle temporali sono molto più facili da implementare in quanto sono pronte per l'uso.

Le domande sono - le tabelle temporali sono abbastanza buone per sostituire Event Sourcing e, in caso contrario, quali sarebbero i vantaggi di uno rispetto all'altro?

    
posta civan 16.05.2017 - 21:12
fonte

1 risposta

2

No. Le tabelle temporali non sostituiscono il sourcing di eventi. Sono tecnologie complementari. Le tabelle temporali eseguono semplicemente una copia dei dati su un'altra tabella prima di aggiornare o eliminare lo stato corrente. La tabella temporale include timestamp in modo da poter eseguire query con AS OF e altre nuove parole chiave temporali. Se si esegue una query normale, si otterrà lo stato corrente solo come se non fosse una tabella temporale.

Il sourcing di eventi può essere considerato come un log delle transazioni o una coda di delta. Gli eventi devono essere tradotti in un modello (ad es. Oggetto o tabella) prima che siano utili.

Una tabella temporale sarebbe più appropriata per mantenere una cronologia delle modifiche sui dati CRUD. Tali dati spesso hanno stabilito vincoli come l'unicità che una tabella relazionale può indirizzare, ma un negozio di eventi non può. Ad esempio, una configurazione del prodotto (ID, SKU, nomi, prezzi, parole chiave, ...) potrebbe essere un'entità appropriata da rappresentare in una tabella temporale e essere in grado di tracciare nel tempo.

Il sourcing di eventi è più appropriato per la registrazione permanente di fatti a cui possono essere interessati più osservatori. Il processo di ordinazione potrebbe essere una cosa appropriata da archiviare come eventi. Questo ha generalmente un inizio definito (ordine effettuato) e fine (ordine consegnato o annullato) e diverse cose che si verificano nel mezzo (pagamento ricevuto, pagamento rifiutato, ordine spedito, ecc.). Diversi gruppi desiderano conoscere questi eventi per coordinare il lavoro: l'evasione richiede elenchi per estrarre gli articoli dal magazzino, la spedizione richiede pesi e dimensioni e liste di imballaggio per organizzare i camion, il supporto vendite richiede informazioni di contatto per gli ordini con problemi, il marketing desidera conoscere le tendenze, ecc. Ognuno di questi gruppi ha i propri obiettivi per i dati. Quindi, avere un modello di dati valido per tutti (una tabella di ordini per domarli tutti) spesso non funziona. Invece ogni gruppo può leggere gli eventi e applicarli al loro modello costruito appositamente. Una tabella temporale non aiuta a realizzare questo scenario.

    
risposta data 17.05.2017 - 01:23
fonte

Leggi altre domande sui tag