Progettazione del database: come gestire il problema "archivio"?

Sono abbastanza sicuro che molte applicazioni, applicazioni critiche, banche e così via lo facciano ogni giorno.

L'idea alla base di tutto ciò è:

• tutte le righe devono avere una cronologia
• tutti i collegamenti devono rimanere coerenti
• dovrebbe essere facile fare richieste per ottenere colonne "attuali"
• i clienti che hanno acquistato oggetti obsoleti dovrebbero comunque vedere ciò che hanno acquistato anche se questo prodotto non fa più parte del catalogo

e così via.

Ecco cosa voglio fare e spiegherò i problemi che sto affrontando.

Tutti i miei tavoli avranno quelle colonne:

• id
• id_origin
• date of creation
• start date of validity
• start end of validity

Ed ecco le idee per le operazioni CRUD:

• create = inserisci una nuova riga con id_origin= id, date of creation= now, start date of validity= now, end date of validity= null (= significa che è il record attivo corrente)
• aggiornamento =
  • read = leggi tutti i record con end date of validity== null
  • aggiorna il record "corrente" end date of validity= null con end date of validity= now
  • creane uno nuovo con i nuovi valori e end date of validity= null (= significa che è il record attivo corrente)
• delete = aggiorna il record "corrente" end date of validity= null con end date of validity= now

Quindi, ecco il mio problema: con molte associazioni. Facciamo un esempio con i valori:

• Tabella A (id = 1, id_origin = 1, inizio = ora, fine = null)
• Tabella A_B (inizio = ora, fine = null, id_A = 1, id_B = 48)
• Tabella B (id = 48, id_origin = 48, inizio = ora, fine = null)

Ora voglio aggiornare la tabella A, record id = 1

• Contrassegno id record = 1 con end = ora

• Inserisco un nuovo valore nella tabella A e ... accidenti ho perso la mia relazione A_B a meno che non duplicassi anche la relazione ... questo finirebbe con una tabella:

• Tabella A (id = 1, id_origin = 1, start = now, end = now + 8mn)

• Tabella A (id = 2, id_origin = 1, start = now + 8mn, end = null)
• Tabella A_B (inizio = ora, fine = null, id_A = 1, id_B = 48)
• Tabella A_B (inizio = ora, fine = null, id_A = 2, id_B = 48)
• Tabella B (id = 48, id_origin = 48, inizio = ora, fine = null)

E ... beh, ho un altro problema: la relazione A_B: devo contrassegnare (id_A = 1, id_B = 48) come obsoleto o meno (A - id = 1 è obsoleto, ma non B - 48)?

Come gestirlo?

Devo progettarlo su larga scala: prodotti, partner e così via.

Qual è la tua esperienza al riguardo? Come faresti (come hai fatto)?

-- Modificare

Ho trovato questo articolo molto interessante , ma non tratta correttamente "obsolescenza a cascata" (= cosa sto chiedendo in realtà)

Non mi è chiaro se questi requisiti siano a fini di controllo o solo semplici riferimenti storici come CRM e carrelli della spesa.

In entrambi i casi, considera di avere una tabella main e main_archive per ogni area principale in cui è richiesta. "Main" avrà solo voci correnti / attive mentre "main_archive" avrà una copia di tutto ciò che sarà mai andato in main. Inserire / aggiornare in main_archive può essere un trigger da inserire / aggiornare in main. Le eliminazioni contro main_archive possono quindi essere eseguite per un periodo di tempo più lungo, se mai.

Per i problemi referenziali come Cust X ha acquistato il Prodotto Y, il modo più semplice per risolvere il problema referenziale di cust_archive -> product_archive è di non eliminare mai le voci da product_archive. In genere, lo zangoletto dovrebbe essere molto più basso in quella tabella, quindi le dimensioni non dovrebbero essere un problema.

HTH.

Ciò si sovrappone alla programmazione funzionale; in particolare il concetto di immutabilità.

Hai una tabella chiamata PRODUCTe un'altra chiamata PRODUCTVERSIONo simile. Quando si modifica un prodotto non si esegue un aggiornamento, è sufficiente inserire una nuova PRODUCTVERSIONriga. Per ottenere le ultime novità, è possibile indicizzare la tabella in base al numero di versione (desc), timestamp (desc) oppure è possibile avere un flag ( LatestVersion).

Ora se hai qualcosa che fa riferimento a un prodotto, puoi decidere a quale tabella indica. Indica l' PRODUCTentità (si riferisce sempre a questo prodotto) o PRODUCTVERSIONall'entità (si riferisce solo a questa versione del prodotto)?

Diventa complicato. Cosa succede se si dispone di immagini del prodotto? Devono puntare alla tabella delle versioni, perché potrebbero essere cambiate, ma in molti casi non lo faranno e non vorrai duplicare inutilmente i dati. Ciò significa che hai bisogno di un PICTUREtavolo e una relazione PRODUCTVERSIONPICTUREmolti-a-molti.

Ho implementato tutte le cose da qui con 4 campi che sono su tutti i miei tavoli:

• id
• DATE_CREATION
• date_validity_start
• date_validity_end

Ogni volta che un record deve essere modificato, lo duplico, contrassegno il record duplicato come "vecchio" = date_validity_end=NOW()e quello corrente come buono date_validity_start=NOW()e date_validity_end=NULL.

Il trucco riguarda le relazioni da molti a molti e da uno a molti: funziona senza toccarli! Riguarda le query che sono più complesse: per interrogare un record in una data precisa (= non ora), ho per ogni join, e per la tabella principale, aggiungere quei vincoli:

WHERE (
  (date_validity_start<=:dateparam AND date_validity_end IS NULL)
  OR
  (date_validity_start<=:dateparam AND date_validity_start>=:dateparam)
)

Quindi, con prodotti e attributi (relazione molti a molti):

SELECT p.*,a.*

FROM products p

JOIN products_attributes pa
ON pa.id_product = p.id
AND (
  (pa.date_validity_start<=:dateparam AND pa.date_validity_end IS NULL)
  OR
  (pa.date_validity_start<=:dateparam AND pa.date_validity_start>=:dateparam)
)

JOIN attributes a
ON a.id = pa.id_attribute
AND (
  (a.date_validity_start<=:dateparam AND a.date_validity_end IS NULL)
  OR
  (a.date_validity_start<=:dateparam AND a.date_validity_start>=:dateparam)
)

WHERE (
  (p.date_validity_start<=:dateparam AND p.date_validity_end IS NULL)
  OR
  (p.date_validity_start<=:dateparam AND p.date_validity_start>=:dateparam)
)

Cosa ne pensi di questo? Sembra semplice e piuttosto efficace per quello che ho fatto in passato. Nella tabella "cronologia", usa un PK diverso. Pertanto, il campo "CustomerID" è il PK nella tabella del cliente, ma nella tabella "cronologia", il PK è "NewCustomerID". "CustomerID" diventa solo un altro campo di sola lettura. Ciò lascia "CustomerID" invariato nella storia e tutte le tue relazioni rimangono intatte.