Nous utilisons un produit tiers pour gérer notre adhésion au centre sportif. Nous avons plusieurs types d'adhésion (par exemple, junior, étudiant, personnel, communauté) et plusieurs états d'adhésion (par exemple, annuel, actif, inactif, suspendu). Malheureusement, le produit enregistre uniquement le type d'adhésion et le statut actuels d'un membre. J'aimerais pouvoir suivre la manière dont le type et le statut de nos membres ont changé au fil du temps.
actuellement, nous avons accès à la conception de la base de données du produit. Il fonctionne sur SQL Server et nous exécutons régulièrement nos propres requêtes SQL contre les tables du produit pour produire nos propres tables. Nous relions ensuite nos tables à des tables pivottes dans Excel pour produire des graphiques. Nous sommes donc familiarisés avec la conception de la base de données et SQL. Cependant, nous sommes bloqués sur la manière de mieux aborder ce problème.
Le produit enregistre les achats d'adhésion des membres et leurs dates de début et d'expiration. Nous pouvons donc recourir à ces données pour déterminer le type et le statut d'un membre à tout moment. Par exemple, s'ils ont acheté une adhésion junior le 1 er janvier 2007 et il a expiré le 31 déc. 2007, puis ils ont acheté un adhésion à un étudiant le 1 juin 2008, nous pouvons voir que leur statut est passé de manière active à inactive à active (en janvier 1, 2008 et 1 juin 2008, respectivement) et leur type est passé de Junior à l'étudiant (le 1 juin 2008).
Essentiellement, nous aimerions essorer les propriétés de type et de statut d'un membre en propriétés temporelles ou < un href = "http://martinfowler.com/ap2/effectivity.html" rel = "NOREFERRER"> EFFETIVITÉ A-LA FOWLER (ou une autre chose qui varie avec le temps).
Notre question (enfin :) - Compte tenu de ce qui précède: quelle conception de la table de base de données recommanderiez-vous que nous utilisions pour contenir ces informations. J'imagine qu'il aurait une colonne pour MemberID afin que nous puissions saisir la table des membres existants. Il aurait également besoin de stocker le statut et le type d'un membre et la plage de date à laquelle ils ont été détenus. Nous aimerions être capables d'écrire facilement des questions contre cette table (s) pour déterminer le nombre de membres de chaque type et de chaque statut que nous avions à un moment donné.
MISE À JOUR 2009-08-25: ont été suivis latéralement et n'ont pas encore eu l'occasion d'essayer les solutions proposées. J'espère faire tôt et choisir une réponse basée sur les résultats.
4 Réponses :
étant donné que votre système est déjà écrit et en place, l'approche la plus simple de ce problème (et celle qui affecte la base de données / code existante le moins) est d'ajouter une table d'historique des membres contenant des membres, un statut, un type et Colonnes de date. Ajoutez ensuite une mise à jour et un déclencheur d'insertion à la table principale. Lorsque cela déclenche le feu, vous écrivez les nouvelles valeurs du membre (ainsi que la date du changement d'état) dans la table d'historique des membres. Vous pouvez alors interroger cette table pour obtenir les histoires pour chaque membre.
Ceci est assez simple à mettre en œuvre et n'affectera pas du tout le système existant.
Je vais écrire ceci pour vous pour une adhésion gratuite. :)
Sourire. Merci d'avoir répondu. Je serais heureux d'offrir une adhésion gratuite, mais il semble que vous soyez aux États-Unis et que nous sommes en Australie, il peut donc ne pas être beaucoup plus utile pour vous.
Mon seul ajout à cette réponse serait de faire en sorte que la table d'historique contienne tous les champs de la table d'adhésion - plus un champ d'horodatage pour la date / heure de la modification et du champ d'utilisateur pour enregistrer qui l'a changé. De cette façon, vous enregistrez tous les changements.
Je pense prendre la natation, alors vous pouvez me voir plus tôt que vous ne le pensez.
Je mettrais les informations d'adhésion à sa propre table avec des dates de début et de fin. Garder le client dans une table séparée. C'est une douleur si vous avez besoin de l'abonnement "actuelle" d'informations tout le temps, mais il existe de nombreuses façons de se déplacer dans lesquelles des requêtes ou des déclencheurs.
Je créerais une base de données de reporting organisée dans un schéma d'étoiles. La dimension d'adhésion serait arrangée temporellement, de sorte qu'il y aurait des lignes différentes pour le même membre à différents moments de temps. De cette façon différentes lignes dans la table de fait pourraient se rapporter à différents points de l'histoire.
Ensuite, je créerais des procédures de mise à jour pour mettre à jour périodiquement la base de données de reporting, dites une semaine, de la base de données principale. C'est là que viendrait le travail principal.
Ensuite, je conduirais les rapports hors de la base de données de rapport. Il est assez facile de faire un schéma d'étoiles faire les mêmes choses qu'une table pivot fait. Si nécessaire, j'aurais une sorte d'outil OLAP pour vous asseoir devant la base de données déclarante.
C'est beaucoup de travail, mais cela paierait au fil du temps.
Je ne peux pas vous recommander suffisamment de lecture pour lire Joe Celko "SQL Smarties - Programmation SQL Advanced SQL". Il possède un chapitre entier sur la conception de la base de données temporelle et sur la manière de (efficacement et efficacement) exécuter des requêtes de projection temporelle, de sélection et de jointure temporelle. Et je ne le ferais pas justice pour même tenter d'expliquer ce qu'il dit dans son chapitre de ce poste.
Il suffit de lire votre profil et j'ai remarqué que vous êtes à Sydney aussi bien mate :)
Je suis à Sydney. Je vais essayer de suivre la référence que vous avez suggérée. Une fois que je suis sur les cendres.
Consultez le bookware à North Sydney - dédié aux livres informatiques. Celko est la référence dans toute base de données / SQL - Mise en œuvre agnostique. Meilleur investissement que j'ai jamais fait dans un livre.
Question connexe sur la série horaire Modèle de données: Stackoverflow .com / questions / 4083464 / ...