Come cronologia di archiviazione di un record complesso

Question

Come cronologia di archiviazione di un record complesso

#1 da (1 voti)

3

Ho nel mio database relazionale tre tabelle come questa: Route - > RouteStore - > Memorizzare. Quindi posso modificare quali negozi possono far parte di un percorso ogni volta (aggiungendo o rimuovendo) e devo mantenere una cronologia di questi cambiamenti. Qualcuno che conosco ha suggerito di formattare i dati in un formato di testo (JSON questo caso) e salvarlo in una nuova tabella.

Il motivo per cui dubito tanto dell'uso della strategia JSON è che se userò i dati storici, dovrò sempre fare cose di programmazione per decodificare i dati prima che io possa usarli. Dato che il database è relazionale, non avrei alcun vantaggio nell'usare qualsiasi tipo di query. Facendolo in questo modo sono consapevole che il salvataggio dei dati sarebbe piuttosto semplice, ma utilizzarlo non sarebbe tanto.

L'utilizzo di questi dati è cruciale, dal momento che devo creare una serie di diversi tipi di rapporti dai dati storici che finirebbero per trasformarsi in un incubo.

C'è un modo migliore per mantenere la cronologia delle modifiche al percorso? Quali alternative dovrei avere?

database database-design relational-database

posta 8370 16.02.2017 - 23:07

fonte

1 risposta

Leggi altre domande sui tag database database-design relational-database

Ordinamento inserzione vs Unisci ordinamento - accesso alla memoria Applicazione con autorizzazioni a livello di colonna definite dall'utente

score 1 · Accepted Answer

Ciò che sembra cercare è letteralmente una tabella cronologica per ogni tabella.

In primo luogo, presumo alcune cose sulle tue tabelle per illustrare il modello:

Route
- Id
- Name
- DateCreated
- DateUpdated
- CreatedByUserId
- UpdatedByUserId

Creerai tabelle "shadow" che contengono esattamente le stesse colonne, ad eccezione di una colonna aggiuntiva "version" o "history history" che funge da chiave primaria, più un'altra colonna che definisce l'operazione eseguita (Insert, Aggiorna o Elimina).

Non vuoi veramente le chiavi esterne per le tabelle reali, se stai facendo DELETE, perché non sarai in grado di cancellare la cronologia. Questo implementa il monitoraggio completo delle modifiche:

RouteHistory
- VersionNumber (Primary key)
- Action (string)
- Id
- Name
- DateCreated
- DateUpdated
- CreatedByUserId
- UpdatedByUserId

Un INSERT nella tabella Route dovrebbe corrispondere a un INSERT in RouteHistory:

Numero versione: 1
Azione: INSERT
Id: (nuovo record Id of Route, ad esempio 723)
Nome: (nome del nuovo record di rotta)
DateCreated: ...
CreatedByUserId: ...

Ora, quando viene aggiornato il record Route 723, si otterrà un altro INSERT in RouteHistory:

Numero versione: 2
Azione: UPDATE
Id: 723
Nome: (nome attuale del percorso)
DataCreatato: (DataCreativa corrente del percorso)
DataAggiornata: (data attuale aggiornata del percorso)
... (ripetere per ogni colonna in Route)

Questo può generare molti dati nel tuo database per le tabelle pesanti delle transazioni, ma ti dà ogni singola modifica a quelle tabelle. Questo è particolarmente utile per scopi di controllo.

Il modo più semplice per sincronizzare i dati nelle tabelle principali con i dati nelle tabelle della cronologia utilizza i trigger nel database, ma non è l'ideale se ci sono alcune transazioni di database in cui non si desidera eseguire il trigger. Poi di nuovo, se stai andando con i trigger di monitoraggio delle modifiche complete, garantisci la precisione.