Datenbankentwurf, um Informationen einer Person zu halten, die sich mit der Zeit ändern?

Question

Wir verwenden ein Produkt eines Drittanbieters, um die Mitgliedschaft in unserem Sportzentrum zu verwalten. Wir haben verschiedene Arten der Mitgliedschaft (zB Junior, Student, Mitarbeiter, Community) und mehrere Mitgliedsstatus (zB Jährlich, Aktiv, Inaktiv, Suspendiert). Leider erfasst das Produkt nur den aktuellen Mitgliedschaftsstatus und -status eines Mitglieds. Ich möchte in der Lage sein, zu verfolgen, wie sich Art und Status unserer Mitglieder im Laufe der Zeit verändert haben.

Gegenwärtig haben wir Zugriff auf das Datenbankdesign des Produkts. Es läuft auf SQL Server und wir führen regelmäßig eigene SQL-Abfragen für die Produkttabellen durch, um eigene Tabellen zu erstellen. Wir verknüpfen dann unsere Tabellen mit Pivot-Tabellen in Excel, um Diagramme zu erstellen. Daher sind wir mit Datenbankdesign und SQL vertraut. Wir sind jedoch fest, wie wir dieses Problem am besten angehen können.

Das Produkt registriert die Mitgliedschaftskäufe eines Mitglieds und deren Start- und Ablaufdatum. Wir können also durch diese Daten arbeiten, um zu jedem Zeitpunkt den Typ und Status eines Mitglieds zu bestimmen. Wenn Sie zum Beispiel am 1. Januar 2007 eine Junior-Mitgliedschaft gekauft haben und diese am 31. Dezember 2007 abgelaufen ist und dann am 1. Juni 2008 eine Studentenmitgliedschaft gekauft hat, können wir sehen, dass ihr Status von aktiv zu inaktiv zu aktiv geändert wurde 1. Juni 2008 und 1. Juni 2008) und ihre Art ging von Junior zu Student (am 1. Juni 2008).

Im Wesentlichen möchten wir die Typ- und Statuseigenschaften eines Mitglieds in temporal properties oder effectivities a-la Fowler (oder etwas anderes, das mit der Zeit variiert) verwandeln.

Unsere Frage (endlich :) - angesichts der oben genannten: Welche Datenbanktabellen-Design würden Sie empfehlen, um diese Mitglied Informationen zu halten. Ich stelle mir vor, dass es eine Spalte für MemberID haben würde, damit wir in die bestehende Member-Tabelle einsteigen können. Außerdem müssen der Status und Typ eines Mitglieds sowie der Zeitraum, für den sie aufbewahrt wurden, gespeichert werden. Wir möchten in der Lage sein, problemlos Abfragen für diese Tabelle (n) zu schreiben, um zu bestimmen, wie viele Mitglieder jedes Typs und Status wir zu einem bestimmten Zeitpunkt hatten.

UPDATE 2009-08-25: Wurden seitwärts verfolgt und hatten noch keine Chance, die vorgeschlagenen Lösungen auszuprobieren. Ich hoffe, dass ich das bald tun werde und eine Antwort basierend auf den Ergebnissen auswählen werde.

Answer 1

Angesichts der Tatsache, dass Ihr System bereits geschrieben und an Ort und Stelle ist, ist der einfachste Weg zu diesem Problem (und die am wenigsten vorhandene Datenbank/Code betroffen), eine Mitgliedschaft Geschichte Tabelle, die MemberID, Status, Typ enthält und Datumsspalten. Fügen Sie dann einen UPDATE- und einen INSERT-Trigger zur Hauptmembertabelle hinzu. Wenn diese Auslöser ausgelöst werden, schreiben Sie die neuen Werte für das Mitglied (zusammen mit dem Datum der Statusänderung) in die Mitgliederhistorientabelle. Sie können dann einfach diese Tabelle abfragen, um die Historien für jedes Mitglied zu erhalten.

Dies ist ziemlich einfach zu implementieren und wird das vorhandene System überhaupt nicht beeinflussen.

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

Answer 2

Ich würde die Mitgliedschaft Informationen in eigene Tabelle mit Start-und Enddaten setzen. Halten Sie den Kunden in separate Tabelle. Dies ist ein Problem, wenn Sie die "aktuelle" Mitgliedschaftsinformation die ganze Zeit benötigen, aber es gibt viele Wege, um das entweder durch Abfragen oder Auslöser zu umgehen.

Answer 3

Ich würde eine Berichtsdatenbank erstellen, die in einem Sternschema organisiert wurde. Die Zugehörigkeitsdimension würde zeitlich angeordnet sein, so dass es zu unterschiedlichen Zeitpunkten unterschiedliche Zeilen für das gleiche Mitglied geben würde. Auf diese Weise können sich verschiedene Zeilen in der Faktentabelle auf verschiedene Punkte im Verlauf beziehen.

Dann würde ich Update-Verfahren für die Aktualisierung der Berichtsdatenbank regelmäßig, sagen wir einmal pro Woche, aus der Hauptdatenbank erstellen. Hier würde die Hauptarbeit kommen.

Dann würde ich die Berichte aus der Berichtsdatenbank fahren. Es ist ziemlich einfach, ein Star-Schema die gleichen Dinge machen zu lassen, die eine Pivot-Tabelle tut. Bei Bedarf würde ich eine Art OLAP-Tool erhalten, um vor der Berichtsdatenbank zu sitzen.

Dies ist eine Menge Arbeit, aber es würde sich mit der Zeit auszahlen.

Answer 4

Ich kann Ihnen nicht genug empfehlen, Joe Celko "Sql für Smarties - erweiterte SQL-Programmierung" zu lesen. Er hat ein ganzes Kapitel über das Design von temporären Datenbanken und wie (zeitnah und effektiv) zeitliche Projection-, Auswahl- und zeitliche Join-Abfragen ausgeführt werden können. Und ich würde ihm nicht gerecht werden, um zu erklären, was er in seinem Kapitel in diesem Post sagt.