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 ENDFaria 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?
Respostas:
Se a consulta for executada com pouca frequência (por exemplo, um relatório), é melhor criar a tabela rapidamente 1 . 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'.
1
select intoconsultas 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:
fonte
how often the data is neededehow expensive the query is?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.
fonte
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 ...
fonte