Percebi que os Crystal Reports feitos por nossa organização e por alguns de nossos fornecedores de software ERA tendem a usar tabelas físicas para os conjuntos de dados de seus relatórios, em vez de usar uma exibição ou um procedimento armazenado para coletar os dados. Ocasionalmente, vi relatórios usarem procedimentos armazenados que usam tabelas físicas em vez de tabelas temporárias para armazenar e manipular conjuntos de dados. Nesses casos, a saída do relatório geralmente existe como uma tabela semelhante rpt_ap_vendorsou semelhante e pode ou não ser desprovida de dados quando não estiver em uso.
Esses são sempre casos em que o relatório é gerado sob demanda, portanto, não é um caso em que um relatório pode ser gerado uma vez e exibido várias vezes e não há vários relatórios/procedimentos armazenados acessando esses dados ao mesmo tempo.
Que razão haveria para usar tabelas físicas para relatórios como este? Existe uma razão lógica, técnica ou relacionada ao desempenho para fazer isso? Ao gerar relatórios, eu pessoalmente sempre usei exibições e procedimentos armazenados com tabelas temporárias ou, melhor ainda, tabelas derivadas para evitar leituras de disco extras envolvendo a limpeza/exclusão de uma tabela temporária.
(+) Razões para criar uma tabela física para armazenar os dados do relatório:
Os dados do relatório são reutilizáveis. Eu aponto Crystal Reports ou SharePoint para a tabela e não me preocupo com a frequência ou quando essas ferramentas ou meus usuários finais acessam os dados. (Bem, até certo ponto, já que a leitura repetida de uma grande tabela de relatórios irá destruir meu cache de buffer.) Também posso manter uma janela deslizante de relatórios antigos para solicitações inevitáveis como: "Você pode gerar o relatório do ano passado novamente? Eu não consigo encontrar o CSV que extraí no momento."
Este é provavelmente o principal motivo pelo qual está configurado dessa forma em seu site. O Crystal Reports pode não ser inteligente o suficiente para armazenar em cache os dados do relatório à medida que os usuários o paginam ou alteram as configurações do relatório. Portanto, na pior das hipóteses, o CR está regenerando seu relatório com cada uma dessas ações - uma operação cara e demorada. Com a tabela física, ele apenas consulta novamente a tabela quantas vezes for necessário.
Definir permissões no relatório é fácil. Você quer ver este relatório? Bem, tudo que você precisa é permissão para ler os resultados, NÃO gerá-los . Portanto, aqui, tenha alguns direitos de leitura nesta tabela em um esquema e grupo de arquivos/espaço de tabela bloqueados.
Ao armazenar manualmente o relatório em cache, você controla e isola o processo de geração dele. Você dá aos leitores do seu relatório mais liberdade para agir e menos com que se preocupar como DBA.
(-) O que você perde com uma tabela de relatório físico:
Em um empregador anterior, alguns dos relatórios levariam horas para serem executados. Os relatórios de final de mês e trimestre foram os piores (8 e 20 horas, respectivamente). Ao calcular os resultados e armazená-los em uma tabela permanente, o usuário pode ver os resultados do relatório por capricho, sem recalcular os números na hora. O processo que calculava os relatórios era capaz de reiniciar se fosse interrompido, o que também ajudava: naquela parte do sul da Flórida, havia várias quedas de energia de um segundo por dia. Embora a empresa tivesse um gerador no local para os dias de mau tempo, nem todos os funcionários tinham no-breaks.
Alguns dos "usuários avançados" queriam poder acessar os dados e processar os números no Excel, para que tivessem acesso somente leitura às tabelas de relatórios.