Qual design é melhor para a transformação de dados?

5

O banco de dados da minha empresa disponibiliza dados para muitos aplicativos externos. Então, preciso transformar os mesmos dados em muitas exibições dinâmicas . Eu posso ver que um antigo desenvolvedor de banco de dados tinha implementado muitas cadeias longas de sequências de chamada de procedimento de função de exibição para fazer a transformação mais comum a todos os aplicativos externos. Eu acho que esta arquitetura e pedidos tão longos (stored proc chama uma função, então a função chama alguma visão e essa visão baseada em outra e assim por diante) é um problema de desempenho, pelo menos o otimizador de consulta não resolve esses problemas (por favor confirme palpites).

É uma boa abordagem? Isso causa degradação do desempenho? Se sim, como posso reimplementar objetos do banco de dados.

Neste momento, vejo estes passos para o fazer:

  • análise da estrutura de dados de origem (dados próprios)
  • análise de todos os sistemas externos (quais formatos o banco de dados deve fornecer)
  • vistas separadas, funções, procs armazenados para todos os subsistemas externos (eu tenho que evitar cadeias longas, comuns a muitos objetos de banco de dados de subsistemas, se é uma causa de problema)
por Zzz 20.01.2011 / 11:42
fonte

2 respostas

4

Já pensou em criar um datamart ? Talvez seja o que seu colega já fez?

Depende muito do seu caso específico, mas eu entendo que você não pode descrever todo o seu negócio em sua pergunta.

Se você é sério sobre isso, eu recomendo-lhe este grande livro que não só descreve como fazê-lo, mas explica profundamente todos os problemas que você poderia encontrar em tais situações.

O Data Warehouse Toolkit

Confiraoutros livros de Ralph Kimball também.

    
por 20.01.2011 / 11:52
fonte
1

Acho que o ex-funcionário tentou criar uma visão lógica dos dados separados da representação física.

Quando os clientes são anexados a Visualizações e / ou procedimentos armazenados, você tem algum espaço para refatorar a representação física sem que os clientes precisem de modificações.

É claro que essa camada lógica adiciona alguma indireção e pode custar tempo extra de processamento. No entanto, isso ainda pode valer a pena de um ponto de vista de manutenção. Poder fazer malabarismos com tabelas e relacionamentos abaixo dessa camada lógica também pode ajudar ao lidar com problemas de desempenho.

Às vezes, ser mais lento não é necessariamente um problema, ainda é rápido o suficiente?

    
por 21.01.2011 / 19:50
fonte