Datenbank-Design zu einer Person, die Informationen zu enthalten, die mit der Zeit ändert?

Question

Wir verwenden ein Drittanbieterprodukt in unserem Sportzentrum Mitgliedschaft zu verwalten. Wir haben mehrere Mitgliedstypen (zB. Junior, Schüler, Mitarbeiter, Gemeinde) und mehrere Mitgliedsstatus (z. B. jährlich, aktiv, inaktiv) suspendiert. Leider zeichnet das Produkt nur ein aktuelle Mitgliedschaft Art und Status des Mitglieds. Ich möchte in der Lage sein, die Art und Weise unserer Mitglieder Lauf der Zeit verändert Typ und Status haben zu verfolgen.

Zur Zeit haben wir Zugriff auf die Datenbank-Design des Produkts. Es läuft auf SQL Server und wir regelmäßig unsere eigenen SQL-Abfragen des Produkts Tabellen ausführen, um unsere eigenen Tabellen zu erzeugen. Wir verbinden dann unsere Tabellen Pivot-Tabellen in Excel-Tabellen zu erzeugen. So sind wir mit Datenbank-Design und SQL vertraut. Allerdings sind wir fest, wie am besten dieses Problem zu nähern.

Das Produkt zeichnet eines Mitglieds Mitgliedschaft Käufe und deren Start- und Ablaufdaten. So können wir wieder durch diese Daten arbeiten, ein Mitglied Typen und Status zu jedem Zeitpunkt zu bestimmen. wenn sie eine Junior-Mitgliedschaft am 1. Januar 2007 und endete am 31. Dezember, kaufte 2007 zum Beispiel, und dann kauften sie einen Studenten-Mitgliedschaft auf 1. Juni 2008, können wir ihren Status sehen von aktiven ging an aktiv inaktiv (auf Jan 1, 2008 und 1. Juni 2008, respectively) und ihre Art ging von Junior zu Schülern (am 1. Juni 2008).

Im Grunde möchten wir ein Mitglied Art und Statuseigenschaften in zeitlichen Eigenschaften drehen oder < a href = "http://martinfowler.com/ap2/effectivity.html" rel = "noreferrer"> Gültigkeiten a-la Fowler (oder eine andere Sache, die mit der Zeit variiert).

Unsere Frage (endlich :) - die oben angegebene: Welche Datenbanktabelle Design würden Sie empfehlen wir dieses Mitglied Informationen halten verwenden. Ich stelle mir vor, es wäre eine Spalte für MemberID haben, so dass wir in den bestehenden Mitglied Tabelle eingeben können. Es wäre auch ein Mitglied Status speichern muß und geben und den Datumsbereich für sie gehalten wurden. Wir möchten in der Lage sein leicht Abfragen für diese Tabelle zu schreiben (s), um zu bestimmen, wie viele Mitglieder jeder Art und Status, den wir zu einem bestimmten Zeitpunkt hatte.

UPDATE 2009-08-25: Haben Seite verfolgt und haben keine Chance, zu versuchen, die vorgeschlagenen Lösungen noch. Ich hoffe, so bald zu tun und wird eine Antwort auf der Grundlage der Ergebnisse aus.

Answer 1

Da Ihr System bereits geschrieben und an Ort und Stelle, ist die einfachste Lösung für dieses Problem (und die, die die vorhandene Datenbank / code Geringsten beeinflusst), ist eine Mitgliedschaft History-Tabelle hinzufügen, die MemberID enthält, Status, Typ und Datumsspalten. Dann eine UPDATE hinzufügen und einen INSERT-Trigger auf das Hauptelement Tisch. Wenn diese Trigger ausgelöst, schreiben Sie die neuen Werte für das Element (zusammen mit dem Datum der Statusänderung) in die Elemente Historientabelle. Sie können dann nur diese Tabelle abfragen, die Geschichten für jedes Mitglied zu erhalten.

Das ist ziemlich einfach zu implementieren, und das bestehende System überhaupt nicht beeinflussen.

Ich werde das für Sie für eine kostenlose Mitgliedschaft schreiben. :)

Answer 2

Ich kann Ihnen nicht genug empfehlen Joe Celko ist zu lesen „SQL für Smarties - advanced SQL-Programmierung“. er hat ein ganzes Kapitel über zeitliches Datenbankdesign und wie man (effeciently und effektiv) läuft Temporal Projektion, Selektion und Temporal Join-Abfragen. Und ich würde ihn nicht gerecht zu versuchen, auch zu erklären, was er in diesem Beitrag in seinem Kapitel sagt.

Answer 3

Ich würde eine Berichtsdatenbank erstellen, die in einem Sternschema organisiert wurde. Die Mitgliedschafts Dimension würde zeitlich angeordnet sein, so dass es zu unterschiedlichen Zeitpunkten unterschiedliche Zeilen für das gleiche Element sein würde. Auf diese Weise unterschiedliche Zeilen in der Faktentabelle zu verschiedenen Punkten in der Geschichte betreffen könnten.

Dann würde ich Update Verfahren für die Aktualisierung der Berichtsdatenbank in regelmäßigen Abständen erstellen, sagen wir einmal pro Woche, von der Hauptdatenbank. Dies ist, wo die Hauptarbeit kommen würde.

Dann würde ich die Berichte aus der Berichtsdatenbank fahren. Es ist ziemlich einfach ein Star-Schema die gleichen Dinge eine Pivot-Tabelle tut tun zu machen. Wenn nötig, würde ich eine Art von OLAP-Tool erhalten vor der Berichtsdatenbank zu sitzen.

Das ist eine Menge Arbeit, aber es würde im Laufe der Zeit auszahlen.

Answer 4

würde ich die Mitgliedschaft Informationen in einem eigenen Tisch mit Start- und Enddatum setzen. Halten Sie die Kunden in separater Tabelle. Dies ist ein Schmerz, wenn Sie die „aktuellen“ Informationen zur Mitgliedschaft des ganzen Zeit brauchen, aber es gibt viele Möglichkeiten, um die entweder durch Abfragen oder Trigger zu erhalten.