design de banco de dados para armazenar informações de uma pessoa que muda com o tempo?

Question

Nós usamos um produto de terceiros para gerenciar a nossa adesão centro desportivo. Temos vários tipos de associação (por exemplo. Júnior, estudante, funcionários, comunidade) e vários status de associação (por exemplo. Anual, ativo, inativo, suspenso). Infelizmente, o produto só registra atual tipo de associação de um membro e status. Eu gostaria de ser capaz de controlar a forma como tipo e estado dos nossos membros têm mudado ao longo do tempo.

No momento, temos acesso ao design de banco de dados do produto. Ele roda em SQL Server e executar regularmente nossas próprias consultas SQL contra tabelas do produto para produzir nossos próprios quadros. Em seguida, ligar nossas mesas de pivô tabelas no Excel para gráficos produzir. Então, nós estamos familiarizados com o design de banco de dados e SQL. No entanto nós estamos presos a respeito de como melhor abordagem deste problema.

O produto registra compras de adesão a membro e suas datas de início e de expiração. Assim, podemos trabalhar para trás através os dados para determinar o tipo e o status de um membro em qualquer ponto no tempo. Por exemplo, se eles compraram uma adesão júnior em 01 de janeiro de 2007 e que expirou em 31 de dezembro de 2007 e, em seguida, eles compraram uma filiação estudante em 01 de junho de 2008, podemos ver o seu estado passou de ativo para inativo para ativo (em Jan 1 de 2008 e 01 de junho de 2008, respectivamente) e seu tipo passou de júnior para estudante (em 01 de junho de 2008).

Essencialmente nós gostaríamos de transformar propriedades tipo e estado de um membro em propriedades temporais ou < a href = "http://martinfowler.com/ap2/effectivity.html" rel = "noreferrer"> efetividades a-la Fowler (ou alguma outra coisa que varia com o tempo).

Nossa pergunta (finalmente :) - dada a acima: o design da tabela de banco de dados que você recomendaria que usamos para manter esta informação do membro. I imaginar que teria uma coluna para MemberID para que possamos chave na tabela de membros existente. Também seria necessário para armazenar o status de um membro e tipo ea gama data em que foram detidos para. Nós gostaríamos de ser capaz de consultas facilmente escrever contra a (s) esta tabela para determinar quantos membros de cada tipo e estado tivemos em um determinado ponto no tempo.

Atualização 2009-08-25: Foram desviada e não tive a chance de experimentar as soluções propostas ainda. A esperança de fazê-lo em breve e irá selecionar uma resposta com base nos resultados.

Answer 1

Tendo em conta que o sistema já está escrito e no lugar, a abordagem mais simples para este problema (e aquele que afeta o banco de dados / código existente a menos), é adicionar uma tabela de histórico de adesão que contém MemberID, status, tipo e colunas de data. Em seguida, adicione uma actualização e um gatilho INSERT para a tabela membro principal. Quando esses gatilhos disparar, você escreve os novos valores para o membro (juntamente com a data da mudança de status) na tabela a história membro. Você pode, então, apenas consultar esta tabela para obter as histórias de cada membro.

Este é bastante simples de implementar, e não afetará o sistema existente em tudo.

Vou escrever isso para você para uma sociedade livre. :)

Answer 2

Eu não posso recomendar o suficiente para ler Joe Celko do "Sql para smarties - programação SQL avançado". ele tem um capítulo inteiro sobre design de banco de dados temporais e como (de forma eficiente e eficaz) executar Projeção Temporal, Selecção e Temporal Junte consultas. E eu não lhe faria justiça para sequer tentar explicar o que ele diz em seu capítulo neste post.

Answer 3

Gostaria de criar um banco de dados relatando que foi organizado em um esquema em estrela. A dimensão de adesão seria organizada temporalmente, de modo que não haveria linhas diferentes para o mesmo membro em diferentes pontos no tempo. Dessa forma, as diferentes linhas na tabela de fato poderia pertencer a diferentes pontos da história.

Em seguida, eu iria criar procedimentos de atualização para atualizar o banco de dados de relatórios periodicamente, digamos uma vez por semana, a partir do banco de dados principal. Este é onde o trabalho principal viria.

Então, eu iria conduzir os relatórios fora do banco de dados de relatórios. É muito fácil de fazer um esquema em estrela fazer as mesmas coisas uma tabela dinâmica faz. Se for necessário, eu iria obter algum tipo de ferramenta de OLAP para sentar na frente do banco de dados de relatórios.

Este é um monte de trabalho, mas seria pagar ao longo do tempo.

Answer 4

Gostaria de colocar a informação de membro em sua própria mesa com datas de início e término. Manter o cliente em uma mesa separada. Esta é uma dor se você precisa do "atual" informação de afiliação o tempo todo, mas há muitas maneiras de contornar isso quer através de consultas ou gatilhos.