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, die Art und Weise zu verfolgen, wie sich der Typ und der 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 erfasst die Mitgliedschaftskäufe eines Mitglieds sowie 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 Elements in zeitliche Eigenschaften oder effectivities a-la Fowler (oder eine andere Sache, die mit der Zeit variiert).
Unsere Frage (endlich :) - angesichts des oben genannten: Welches Datenbanktabellen-Design würden Sie empfehlen, um diese Mitgliederinformationen zu speichern. 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 verfolgt und hatten bisher keine Chance, die vorgeschlagenen Lösungen auszuprobieren. Hoffe, das bald zu tun und wird eine Antwort basierend auf den Ergebnissen auswählen.
Da Ihr System bereits geschrieben und an Ort und Stelle ist, besteht der einfachste Ansatz zu diesem Problem (und dem, der die vorhandene Datenbank / den Code am wenigsten beeinflusst) darin, eine Mitgliedschaftsverlaufstabelle hinzuzufügen, die MemberID, Status, Typ und enthält 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 relativ einfach zu implementieren und hat keinerlei Auswirkungen auf das vorhandene System.
Ich schreibe dir das für eine kostenlose Mitgliedschaft. :)
Ich kann Ihnen nicht genug empfehlen, Joe Celkos "SQL for Smarties - Fortgeschrittene 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 temporäre Join-Abfragen ausgeführt werden können. Und ich würde ihm nicht gerecht werden, um zu erklären, was er in seinem Beitrag in diesem Post sagt.
Ich würde eine Berichtsdatenbank erstellen, die in einem Sternschema organisiert ist. 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-Prozeduren erstellen, um die Berichtsdatenbank regelmäßig, etwa einmal pro Woche, aus der Hauptdatenbank zu aktualisieren. Dies ist, wo die Hauptarbeit kommen würde.
Dann würde ich die Berichte von der Berichtsdatenbank abziehen. 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.
Das ist eine Menge Arbeit, aber es würde sich mit der Zeit auszahlen.
Ich würde die Mitgliedschaftsinformationen in eine eigene Tabelle mit Start- und Enddatum setzen. Halten Sie den Kunden in separate Tabelle. Dies ist ein Schmerz, wenn Sie die "aktuelle" Mitgliedschaft Informationen die ganze Zeit benötigen, aber es gibt viele Möglichkeiten, um das entweder durch Abfragen oder Auslöser umgehen.
Tags und Links sql sql-server database-design temporal-database