la conception de base de données pour tenir les informations d'une personne qui change avec le temps?

Question

Nous utilisons un produit tiers pour gérer nos membres du centre sportif. Nous avons plusieurs types d'adhésion (par exemple. Junior, étudiant, personnel, communauté) et plusieurs statuts d'adhésion (par exemple. Annuelle, actif, inactif, suspendu). Malheureusement, le produit enregistre uniquement le type actuel et le statut de membre d'un membre. Je voudrais être en mesure de suivre la façon dont le type et le statut de nos membres ont changé au fil du temps.

À l'heure actuelle, nous avons accès à la conception de la base de données du produit. Il fonctionne sur SQL Server et nous courons régulièrement nos propres requêtes SQL sur les tables du produit pour produire nos propres tables. Nous vous redirigent ensuite nos tables de pivot tables dans Excel pour produire des graphiques. Nous sommes donc familiers avec la conception de base de données et SQL. Cependant, nous sommes coincés à la façon d'aborder au mieux ce problème.

Le produit enregistre les achats et leurs dates de début et d'expiration membres d'un membre. Nous pouvons donc travailler à travers ces données pour déterminer le type et le statut de membre à tout moment. Par exemple, s'ils ont acheté une adhésion junior le 1er janvier 2007 et il a expiré le 31 déc 2007, puis ils ont acheté un abonnement étudiant le 1 juin 2008, nous pouvons voir leur statut est passé de actif inactif à actif (sur Jan 1, 2008 et le 1 juin 2008, respectivement) et leur type est passé de junior à l'étudiant (le 1 juin 2008).

Essentiellement, nous aimerions transformer un de type de membres et les propriétés statut en ou < a href = "http://martinfowler.com/ap2/effectivity.html" rel = "noreferrer"> effectivités a-la Fowler (ou autre chose qui varie avec le temps).

Notre question (enfin :) - étant donné ce qui précède: quelle conception de la table base de données recommanderiez-vous que nous utilisons pour tenir ces informations de membres. J'imagine que ce serait une colonne pour MemberID afin que nous puissions clé dans la table de membres actuels. Il devrait également conserver le statut de membre et type et la plage de dates ils ont été détenus. Nous aimerions être en mesure de déterminer le nombre de membres de chaque type et le statut que nous avons eu à un moment donné dans le temps d'écrire facilement des requêtes sur cette table (s).

Mise à jour 2009-08-25: Ont été suivis côté et n'ont pas eu la chance d'essayer encore les solutions proposées. L'espoir de le faire rapidement et sélectionnera une réponse en fonction des résultats.

Answer 1

Étant donné que votre système est déjà écrit et mis en place, l'approche la plus simple à ce problème (et celui qui affecte la base de données existante / code du moins), est d'ajouter une table d'historique d'adhésion qui contient MemberID, le statut, le type et colonnes de date. Ensuite, ajoutez un UPDATE et un déclencheur INSERT à la table principale membre. Lorsque ces déclencheurs feu, vous écrivez les nouvelles valeurs pour le membre (ainsi que la date du changement d'état) dans la table d'historique de membre. Vous pouvez alors simplement interroger ce tableau pour obtenir les histoires pour chaque membre.

Ceci est assez simple à mettre en œuvre, et n'affectera pas le système existant du tout.

Je vais écrire pour vous pour une adhésion gratuite. :)

Answer 2

Je ne peux pas vous recommander assez pour lire Joe Celko « pour la Sql smarties - programmation avancée sql ». il a un chapitre entier sur la conception de base de données temporelle et comment (effeciently et efficace) exécuter temporelle Projection, Sélection et temporelles requêtes de jointure. Et je ne lui rendre justice pour tenter même d'expliquer ce qu'il dit dans son chapitre dans ce message.

Answer 3

Je voudrais créer une base de données de rapports qui a été organisé dans un schéma en étoile. La dimension d'adhésion serait organisée dans le temps, de sorte qu'il y aurait des lignes différentes pour le même membre à différents points dans le temps. De cette façon, les différentes lignes de la table de faits pourraient se rapporter à différents points dans l'histoire.

Ensuite, je créerais des procédures de mise à jour pour mettre à jour la base de données de rapports périodiquement, par exemple une fois par semaine, à partir de la base de données principale. C'est là le travail principal serait venu.

Alors, je conduirais les rapports à partir de la base de données de rapports. Il est assez facile de faire un schéma en étoile faire les mêmes choses un tableau croisé dynamique fait. Si nécessaire, je reçois une sorte d'outil OLAP pour asseoir devant la base de données de rapports.

Il est beaucoup de travail, mais il serait rentable au fil du temps.

Answer 4

Je mettrais les informations d'adhésion dans son propre tableau avec des dates de début et de fin. Garder le client dans le tableau séparé. Ceci est une douleur si vous avez besoin d'informations d'adhésion « en cours » tout le temps, mais il y a plusieurs façons de contourner ce soit par le biais de requêtes ou déclencheurs.