Projektowanie bazy danych do przechowywania informacji o osobie, która zmienia się wraz z upływem czasu?

Question

Używamy produktów innych firm do zarządzania członkostwem w naszym centrum sportowym. Mamy kilka rodzajów członkostwa (np. Junior, student, personel, społeczność) i kilka statusów członkostwa (np. Roczny, aktywny, nieaktywny, zawieszony). Niestety produkt rejestruje tylko bieżący typ członkostwa i status członka. Chciałbym móc śledzić sposób, w jaki typ i status członków zmieniał się z czasem.

Obecnie mamy dostęp do projektu bazy danych produktu. Działa na serwerze SQL Server i regularnie uruchamiamy własne zapytania SQL względem tabel produktu, aby tworzyć własne tabele. Następnie łączymy nasze tabele z tabelami przestawnymi w programie Excel, aby tworzyć wykresy. Znamy więc projektowanie baz danych i SQL. Jednak utknęliśmy, jak najlepiej podejść do tego problemu.

Produkt rejestruje zakupy członków oraz ich daty rozpoczęcia i zakończenia. Możemy więc przeglądać te dane, aby określić typ i status członka w dowolnym momencie. Na przykład, jeśli kupili członkostwo dla nieletnich 1 stycznia 2007 r. I wygasną 31 grudnia 2007 r., A następnie kupili członkostwo dla studentów w dniu 1 czerwca 2008 r., Możemy zobaczyć ich status z aktywnego na nieaktywny do aktywnego (na styczeń 1, 2008 i 1 czerwca 2008 r., Odpowiednio) i ich typ przeszedł z juniora na studenta (1 czerwca 2008 r.).

Zasadniczo chcielibyśmy zmienić właściwości typu i statusu członka na temporal properties lub effectivities a-la Fowler (lub inną rzecz, która zmienia się wraz z upływem czasu).

Nasze pytanie (w końcu :) - biorąc pod uwagę powyższe: jaki projekt tabeli bazy danych poleciłby nam wykorzystać do przechowywania informacji o tym użytkowniku. Wyobrażam sobie, że będzie miał kolumnę dla MemberID, abyśmy mogli wprowadzić klucz do istniejącej tabeli członków. Musiałby również przechowywać status i typ członka oraz zakres dat, w jakim były przechowywane. Chcielibyśmy móc łatwo pisać zapytania w odniesieniu do tej tabeli (tabel), aby określić, ilu członków każdego rodzaju i statusu mieliśmy w danym momencie.

AKTUALIZACJA 2009-08-25: Zostały poboczne i nie miały jeszcze okazji wypróbować proponowanych rozwiązań. Mam nadzieję, że zrobię to wkrótce i wybiorę odpowiedź na podstawie wyników.

Answer 1

Biorąc pod uwagę, że twój system jest już napisany i zainstalowany, najprostsze podejście do tego problemu (i takie, które ma najmniejszy wpływ na istniejącą bazę danych/kod), polega na dodaniu tabeli historii członkostwa zawierającej identyfikator, status, typ i kolumny daty. Następnie dodaj wyzwalacz UPDATE i INSERT do głównej tabeli elementów. Po uruchomieniu tych wyzwalaczy wpisujesz nowe wartości dla członka (wraz z datą zmiany statusu) w tabeli historii członków. Możesz wtedy po prostu przesłać zapytanie do tej tabeli, aby uzyskać historie dla każdego członka.

Jest to dość łatwe do wdrożenia i nie ma żadnego wpływu na istniejący system.

Napiszę to dla ciebie za darmowe członkostwo. :)

Answer 2

Chciałbym umieścić informacje o członkostwie w swojej własnej tabeli z datami rozpoczęcia i zakończenia. Trzymanie klienta w osobnej tabeli. To jest problem, jeśli potrzebujesz "aktualnych" informacji o członkostwie przez cały czas, ale istnieje wiele sposobów na obejście tego poprzez zapytania lub wyzwalacze.

Answer 3

Chciałbym utworzyć bazę danych raportowania, która została zorganizowana w schemat gwiaździsty. Wymiar członkostwa zostałby zorganizowany tymczasowo, aby w różnych punktach czasowych istniały różne rzędy dla tego samego członka. W ten sposób różne wiersze w tabeli faktów mogą odnosić się do różnych punktów historii.

Następnie utworzyłbym procedury aktualizowania aktualizacji bazy danych raportowania okresowo, powiedzmy raz w tygodniu, z głównej bazy danych. To tu nadejdzie główna praca.

Następnie wyrzuciłbym raporty z bazy danych raportowania. Użycie schematu gwiaździstego jest bardzo łatwe, tak jak robi to tabela przestawna. Jeśli to konieczne, otrzymam narzędzie OLAP, które będzie znajdować się przed bazą danych raportowania.

To dużo pracy, ale z czasem się opłaci.

Answer 4

Nie mogę polecić wystarczająco dużo, aby przeczytać "Sql dla smartiesa - programowanie SQL" autorstwa Joe Celko. ma cały rozdział o projektowaniu tymczasowej bazy danych ORAZ o tym, jak (skutecznie i efektywnie) uruchamiać kwerendy Temporal Projection, Selection i Temporal Join. I nie zrobiłbym mu sprawiedliwości, nawet próbując wyjaśnić, co mówi w swoim rozdziale w tym poście.