08-24-2008
|
|
Fórum Robot Girl
|
|
|
Join Date: Sep 2000
Posts: 22.270
|
|
|
Em evento Lojas e Temporal Databases
2008-08-24T19: 37:00.004 +03:00
Eu sou um velho homem que carrega lenços, como um presente, em qualquer lugar que ele vai, é útil para múltiplos usos, afinal -, enquanto, no passado, todas as lojas em Israel procedeu bolso e foi bastante popular um produto, para alguns motivo, ele saiu de moda, e tenho dificuldade para renovar o estoque de lenços de bolso e, neste sentido, eu gostaria de poder passo por um minuto para o passado, comprar duas dúzias de lenços de bolso e de regresso. No passado, eu fui envolvido no trabalho de cerca de temporal de dados e até mesmo co-editado um livro nesta área. Temporal bases tinha dois objectivos principais:
(1). Manter dados históricos, e permitir fácil recuperação desses dados
(2). Ativar a emitir consultas "como de" qualquer ponto no tempo, ou seja, a questão que a consulta tenha em conta a informação que estava disponível em um determinado ponto no tempo (e não como pode ser visto a partir de "agora") - novamente, voltando para o passado.
Pode-se perguntar por que estou escrevendo sobre temporais de dados de hoje, bem - a questão das bases temporais está voltando quando se pensa "evento lojas", eu sei que alguns dos meus colegas de dados não gostar do termo "evento loja" ou " repositório evento ", uma vez que não inclui explicitamente a palavra" banco ", mas para mim, usando apenas um SGBD é possível execução, enquanto outros, como a grelha cache também são possíveis - mas este é um assunto para outro debate.
Anyway - por que precisamos de um "evento loja" - em alguns casos, precisamos de manter a acontecimentos históricos e utilizá-los, em alguns casos, até mesmo aplicar padrão detecção sobre os acontecimentos passados. Para fins de auditoria que também pode querer questão "como de" consultas. Note que a representação temporal dos eventos pode ser feita de acordo com múltiplas dimensões temporais (ver discussão sobre a dimensão temporal dos eventos). Uma das características temporais de dados são de que eles são "apenas append" bases de dados, ou seja: registos de dados podem ser adicionados, mas não alterado ou revogado; modificação e deleções são operadores lógicos que criar outras instâncias, mantendo os antigos. Isso está ligado a uma das propriedades dos eventos -- imutabilidade, O que é efectivamente uma propriedade que tem ainda controverso debate sobre - em que condições é necessária. Temporal bases parecem ser uma boa maneira de representar os eventos históricos.
Alguns concluindo comentários:
(1). Atual DBMS não suportam bases temporais como primitivo, embora temporal bases foram construídas como uma segunda camada acima deles.
(2). Nem todos os eventos têm de ser persistentes para a transformação histórica, esta é uma propriedade de evento do tipo, e as suas políticas de retenção. Diferentes acontecimentos precisam ser persistiu para diferentes fins.
(3). A questão da linguagem que deve ser utilizada para processar a "evento lojas" é também uma questão de opinião, alguns acreditam que o SQL é a resposta (no entanto, para alguns modelos, é um incómodo linguagem), há uma tentativa de estender a linguagem SQL com extensões padrão, aqui vou citar um sábio, Paul Vincent, que escreveu em uma nota para desta postagem : Isto será particularmente boa notícia para aqueles que gostam de seus comandos SQL para executar a múltiplas páginas ... Outra opção é a utilização em linha linguagem padrão que é usado para on-line padrões, e traduzido para SQL (ou uma de suas variações).
Há várias questões que precisam ainda mais profunda discussão -, mas por hoje chega.
Fonte ...
|
Mais UNIX e Linux Fórum Tópicos Você pode achar Helpfull
Powered by 
Hybrid Mode
