Progettazione di database per tenere le informazioni di una persona che cambia con il tempo?

Question

Usiamo un prodotto di terze parti per gestire la nostra appartenenza centro sportivo. Abbiamo diversi tipi di appartenenza (ad es. Minore, studente, personale, comunità) e diversi stati di appartenenza (ad es. Annuale, attivo, inattivo, sospeso). Purtroppo il prodotto registra solo tipo di appartenenza corrente di un membro e lo stato. Mi piacerebbe essere in grado di monitorare il modo in cui tipo e lo stato dei nostri membri sono cambiati nel corso del tempo.

Al momento, abbiamo accesso alla progettazione di database del prodotto. Funziona su SQL Server e abbiamo regolarmente eseguire le nostre query SQL sulle tabelle del prodotto per produrre le nostre tavole. Abbiamo poi colleghiamo le nostre tavole di pivot tabelle in Excel per produrre grafici. Quindi siamo familiarità con la progettazione di database e SQL. Tuttavia siamo bloccati su come affrontare meglio questo problema.

Il prodotto record di un membro acquisti di appartenenza e le loro date di inizio e di scadenza. Così possiamo lavorare di nuovo attraverso i dati per determinare il tipo e lo stato di un membro in qualsiasi punto nel tempo. Ad esempio, se hanno comprato un abbonamento junior 1 Gennaio 2007 ed è scaduto il 31 dicembre 2007 e poi hanno comprato un abbonamento studente su 1 giugno 2008, possiamo vedere il loro stato è passato da attivo a inattivo ad attivo (il gen 1, 2008 e 1 giugno 2008, rispettivamente) e il loro tipo è passato da juniores a studente (il giu 1, 2008).

In sostanza vorremmo trasformare tipo e lo stato proprietà di un membro in proprietà temporali o < a href = "http://martinfowler.com/ap2/effectivity.html" rel = "noreferrer"> effectivities a-la Fowler (o qualche altra cosa che varia con il tempo).

La nostra domanda (finalmente :) - dato quanto sopra: quello che database di progettazione tabella consiglieresti usiamo per tenere queste informazioni utente. Immagino che avrebbe una colonna per MemberID in modo che possiamo chiave nella tabella di membro esistente. Sarebbe anche necessario memorizzare lo stato di un utente e digitare e l'intervallo di date che si sono tenute per. Vorremmo essere in grado di scrivere con facilità query su questa tabella (s) per determinare il numero di membri di ogni tipo e lo stato che abbiamo avuto in un determinato momento.

UPDATE 2009-08-25: Sono stati sviato e non hanno avuto la possibilità di provare le soluzioni proposte finora. Spero di farlo presto e selezionerà una risposta in base ai risultati.

Answer 1

Dato che il sistema è già scritto e nel luogo, l'approccio più semplice a questo problema (e quello che colpisce il database / codice esistente il meno), è quello di aggiungere una tabella di storia di appartenenza che contiene MemberID, lo stato, il tipo e colonne di data. Quindi aggiungere un UPDATE e un trigger INSERT alla tabella membro principale. Quando questi trigger fuoco, si scrive i nuovi valori per il membro (insieme con la data del cambiamento di stato) nella tabella della cronologia membro. È possibile poi basta interrogare questa tabella per ottenere le storie per ogni membro.

Questo è abbastanza semplice da implementare, e non influenzerà il sistema esistente a tutti.

ti scrivo questo per voi per un abbonamento gratuito. :)

Answer 2

Non posso raccomandare abbastanza di leggere di Joe Celko "SQL per smarties - programmazione SQL avanzati". ha un intero capitolo sulla progettazione di database temporale e come (efficientemente ed efficacemente) eseguire temporale di proiezione, di selezione e temporali Join query. E io non gli farei giustizia anche a tentare di spiegare quello che dice nel suo capitolo in questo post.

Answer 3

Vorrei creare un database di report che è stato organizzato in uno schema a stella. La dimensione adesione sarebbe disposto temporalmente, in modo che ci sarebbero diverse righe per lo stesso elemento in diversi punti nel tempo. In questo modo le diverse righe della tabella dei fatti potrebbero riguardare diversi punti della storia.

Poi vorrei creare procedure di aggiornamento per l'aggiornamento periodicamente il database di report, dire una settimana, dal database principale. Questo è dove il lavoro principale sarebbe venuto.

Poi, vorrei guidare i rapporti fuori dal database di report. E 'abbastanza facile fare uno schema a stella fare le stesse cose una tabella pivot fa. Se necessario, mi piacerebbe avere un qualche tipo di strumento OLAP di sedersi davanti al database di report.

Questo è un sacco di lavoro, ma sarebbe pagare nel corso del tempo.

Answer 4

Io metterei informazioni appartenenza a essa la propria tabella con le date di inizio e fine. Mantenere il cliente nella tabella separata. Questo è un dolore se avete bisogno della "corrente" informazioni di appartenenza per tutto il tempo, ma ci sono molti modi per aggirare che o tramite query o trigger.