diseño de base de datos para almacenar la información de una persona que cambia con el tiempo?

Question

Utilizamos un producto de terceros para administrar nuestra membresía centro deportivo. Tenemos varios tipos de miembros (por ejemplo. Secundaria, los estudiantes, el personal, la comunidad) y varios estados miembros (por ejemplo. Anual, activo, inactivo, suspendido). Por desgracia, el producto sólo registra el tipo de membresía actual de un miembro y de estado. Me gustaría ser capaz de seguir el camino tipo y el estado de nuestros miembros han cambiado con el tiempo.

En la actualidad, tenemos acceso a la base de datos de diseño del producto. Se ejecuta en SQL Server y que ejecuta regularmente nuestras propias consultas SQL contra las tablas del producto para producir nuestros propios cuadros. a continuación ligamos nuestras mesas de pivote tablas en Excel para producir gráficos. Así que estamos familiarizados con el diseño de bases de datos y SQL. Sin embargo estamos atrapados en cuanto a la forma de abordar mejor este problema.

El producto registra las compras de miembros de un miembro y sus fechas de inicio y vencimiento. Así podemos trabajar hacia atrás a través de los datos para determinar el tipo y el estado de un miembro en cualquier punto en el tiempo. Por ejemplo, si compraron una membresía junior, el 1 de enero de 2007 y que expiró el 31 dic, 2007 y compraron una membresía de estudiante el 1 jun, 2008, podemos ver su estado pasó de activo a inactivo a activo (en enero 1, 2008 y 1 de Jun, 2008, respectivamente) y su tipo fue de menor a estudiante (el 1 jun, 2008).

En esencia nos gustaría convertir tipo y estado de las propiedades de un miembro en propiedades temporales o < a href = "http://martinfowler.com/ap2/effectivity.html" rel = "noreferrer"> efectividades a-la Fowler (o alguna otra cosa que varía con el tiempo).

Nuestra pregunta (por fin :) - Por todo lo anterior: ¿qué base de datos de diseño de la tabla le recomendaría que usamos para mantener esta información de miembro. Me imagino que sería tener una columna para MemberID para que podamos clave en la Tabla miembros actuales. También necesitaría para almacenar el estado de un miembro y el tipo y el intervalo de fechas que se llevaron a cabo para. Nos gustaría ser capaz de escribir fácilmente consultas en esta tabla (s) para determinar el número de miembros de cada tipo y el estado que tuvimos en un punto dado en el tiempo.

2009-08-25 ACTUALIZACIÓN: se han rastreado a lado y no han tenido la oportunidad de probar las soluciones propuestas todavía. Espero que sea pronto y seleccionará una respuesta basada en los resultados.

Answer 1

Dado que el sistema ya está escrita y en su lugar, el enfoque más simple a este problema (y la que afecta a la base de datos / código de la menor existente), es añadir una tabla de historial de miembros que contiene MemberID, estado, tipo y columnas de fecha. A continuación, añadir una actualización y un desencadenador de inserción a la tabla miembro principal. Cuando estos factores desencadenantes fuego, que escribe los nuevos valores para el miembro (junto con la fecha del cambio de estado) en la tabla de historial miembro. A continuación, puede simplemente consultar esta tabla para obtener las historias de cada miembro.

Esto es bastante fácil de implementar, y no afectará el sistema existente en absoluto.

Voy a escribir esto para usted obtener una suscripción gratuita. :)

Answer 2

No puedo recomendar lo suficiente para leer de Joe Celko "SQL para sabelotodos - programación SQL avanzado". que tiene todo un capítulo sobre el diseño de base de datos temporal y cómo (de manera eficiente y eficaz) ejecutar proyección temporal, selección y temporales consultas de unión. Y yo no le haría justicia a siquiera intentar explicar lo que dice en su capítulo en este post.

Answer 3

Me gustaría crear una base de datos de informes que se organiza en un esquema de estrella. La dimensión de miembros estaría dispuesto temporalmente, de modo que no habría diferentes filas para el mismo miembro en diferentes puntos de tiempo. De esa manera los diferentes filas de la tabla de hechos podrían pertenecer a diferentes puntos de la historia.

A continuación, me gustaría crear procedimientos de actualización para actualizar la base de datos de informes periódicamente, por ejemplo una vez por semana, a partir de la base de datos principal. Aquí es donde vendría el trabajo principal.

A continuación, me gustaría conducir los informes fuera de la base de datos de informes. Es bastante fácil hacer un esquema en estrella hacer las mismas cosas una tabla dinámica hace. Si es necesario, me gustaría conseguir algún tipo de herramienta OLAP para sentarse frente a la base de datos de informes.

Esto es mucho trabajo, pero sería pagar con el tiempo.

Answer 4

Me gustaría poner la información de miembros en su propia mesa con fechas de inicio y fin. Mantener al cliente en la tabla separada. Este es un problema si se necesita la información "actual" de miembros todo el tiempo pero hay muchas maneras de evitar que, o bien a través de consultas o desencadenantes.