Como posso identificar quando criar uma nova tabela para armazenar dados que podem ser obtidos em uma consulta?

Temos uma tabela de pagamento e os agentes recebem comissão sobre os pagamentos. A comissão baseia-se em alguns fatores diferentes, como o tempo que levou para receber o pagamento, para que haja alguns cálculos envolvidos ao determinar a taxa de comissão que o agente recebe, mas nada obscenamente complexo.

Por exemplo, provavelmente nunca será mais complexo do que isso:

SELECT Payments.Amount * CASE 
    WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 1 THEN Rates.Rate1
    WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 2 THEN Rates.Rate2
    ELSE Rates.Rate3 END

Faria sentido criar uma segunda tabela para armazenar esses dados em vez de consultá-los sempre que necessário? Ou devo ficar apenas com consultas em tempo de execução que extraem os dados sempre que solicitados?

E, mais importante, quais são os fatores a serem usados ao determinar se uma consulta deve ser executada a qualquer momento que os dados forem necessários ou se os dados devem ser armazenados em uma tabela separada própria?

sql-server sql-server-2005 query-performance

— Rachel
fonte

Uma pergunta importante é 'com que frequência as pessoas desejam consultar esses dados?' É um relatório ou uma tela com tráfego intenso no aplicativo?

— ConcernedOfTunbridgeWells

@ConcernedOfTunbridgeWells Nesse caso, é um relatório que é executado algumas vezes por mês, talvez com mais frequência, se permitirmos que os agentes executem o relatório para visualizar sua comissão.

— Rachel

Provavelmente, é melhor transformá-lo em uma tabela de relatórios em um processo noturno, e a comissão é "a partir da noite passada". Se você tiver um processo fechado, no qual precisará fechar, relate-o e poderá fornecer um recurso no aplicativo para forçar uma reconstrução.

— ConcernedOfTunbridgeWells

Datas "DeDe" são bastante comuns com esses tipos de operações em um contexto financeiro, na minha experiência. Portanto, uma tabela (como observa @ConcernedOfTunbridgeWells) com essa data "AsOf" deve ser perfeitamente aceitável.

— swasheck

Post relacionado: dba.stackexchange.com/q/7592/2660

— Nick Chammas

Respostas:

Se a consulta for executada com pouca frequência (por exemplo, um relatório), é melhor criar a tabela rapidamente ¹ . Se a consulta for executada com freqüência e a tabela temporária for necessária para o desempenho, você poderá ter um problema.

Se a tabela for barata de construir, faça-a como uma tabela temporária. Contanto que o banco de dados seja rápido o suficiente, você poderá se safar. No entanto, você precisará manter um olho no desempenho.
Se a tabela não precisar estar totalmente atualizada, mas será objeto de atividade de relatório relativamente frequente, uma reconstrução periódica provavelmente é o melhor caminho a percorrer.
Se a tabela for cara de construir, mas precisar estar atualizada, você pode precisar gerenciá-la como uma estrutura desnormalizada, mantida como uma exibição indexada ou por meio de gatilhos. Isso é um pouco mais complicado e sobrecarrega as operações de gravação.

Em casos mais extremos (por exemplo, grandes volumes de dados), você pode precisar de uma abordagem híbrida, na qual dados históricos são consultados a partir de uma estrutura desnormalizada otimizada para desempenho e os dados atuais são consultados no aplicativo ao vivo.

Os casos mais extremos disso podem levar você a feeds de data mart de baixa latência e soluções OLAP híbridas; portanto, esse é de longe o mais complexo em termos de profundidade da profundidade da toca do coelho. É melhor evitar a menos que você tenha um requisito genuíno.

No caso descrito acima, uma reconstrução periódica de uma tabela de relatórios parece apropriada. Se você precisar fechar no meio do dia para executar relatórios, poderá fornecer um recurso para forçar uma atualização do aplicativo. Caso contrário, execute-o em um processo durante a noite e os agentes poderão ver sua comissão 'como à meia-noite do dia útil anterior'.

¹ select into consultas criando tabelas temporárias são bastante rápidas no SQL Server porque as operações de inserção são minimamente registradas.

Para resumir, use os seguintes fatores para determinar se você deve ter uma nova tabela para seus dados ou não:

Com que frequência os dados são necessários
Como é caro obter os dados
Como os dados precisam ser atualizados

— ConcernedOfTunbridgeWells
fonte

Então, basicamente, os únicos dois fatores que você usa para determinar se precisa de uma tabela permanente para os dados, em vez de consultá-los quando necessário, são how often the data is needede how expensive the query is?

— Rachel

@ Rachel - Além disso, 'até que ponto os dados precisam estar atualizados?'

— ConcernedOfTunbridgeWells

Uma questão não abordada na resposta aceita é "você precisa desse valor ao longo do tempo" e "a fórmula pode mudar".

Por exemplo, considere o exemplo da comissão. Se a comissão for paga, o valor deve ser armazenado, pois é uma figura histórica do que realmente foi pago. A maneira de calcular as comissões pode mudar no próximo mês (e frequentemente muda), mas isso não muda o que realmente foi pago e deve ser armazenado separadamente.

É a mesma idéia que armazenar o preço que o cliente realmente pagou por um produto (após um cálculo de descontos etc.), em vez de depender de uma fórmula em relação a uma tabela de preços para fazer qualquer coisa, exceto o cálculo inicial, pois o preço do produto no próximo mês pode não ser igual ao preço quando o cutomer fez o pedido.

Se você precisar de um registro histórico de qual era o valor em um determinado momento, sempre armazene esse valor depois de usar a fórmula para a calibração inicial.

— HLGEM
fonte

Obrigado, isso é definitivamente algo a considerar ao tomar esse tipo de decisão. Desta vez, o valor não será alterado porque a taxa de comissão é definida uma vez por agente e por cliente quando o cliente é obtido, e a taxa usada é baseada na data do pagamento e na data em que recebemos o cliente, nenhuma das quais são valores que mudam.

— Rachel

@ Rachel - Nenhum dos valores que você planeja alterar no momento. Claro, se eles fazem mudança que você sempre pode criar uma tabela de dados históricos, nesse momento, se você precisar dele, contanto que você não se esqueça sobre a questão.

— Psr

Provavelmente não é de interesse se você estiver bloqueado em um banco de dados específico, mas o MariaDB (baseado no MySQL) tem algo maravilhoso chamado "colunas virtuais" que podem ser calculadas on-the-fly ou armazenadas em cache no armazenamento real, mas automaticamente. recalculado conforme necessário. Perdi essa funcionalidade desde que deixei o FileMaker Pro para o mundo SQL há muitos anos ...

— Jan Steinman
fonte