DOUBLE vs DECIMAL no MySQL: revisitando o debate sobre precisão

É um refrão comum que DOUBLE deve ser evitado para armazenar valores monetários em bancos de dados MySQL devido a possíveis problemas de precisão. No entanto, um cenário prático levanta questões sobre a validade desta recomendação.

Equilibrando Preocupações de Precisão com Considerações Práticas

O cenário dado envolve um sistema legado com numerosas colunas DOUBLE para armazenamento de dinheiro. Apesar da ausência de operações aritméticas SQL, as preocupações residem no potencial de perda de precisão durante o armazenamento e recuperação.

Argumentos contra a conversão

• Não efeitos adversos: Apesar de seis anos de uso, nenhum bug relacionado à precisão foi observado.
• Precisão suficiente: A precisão de 15 dígitos do DOUBLE acomoda a precisão decimal necessária de 2-8 dígitos.
• Cálculos externos: Cálculos monetários são realizados em Java usando BigDecimal, minimizando o impacto da formatação de dados MySQL.

Argumentos para cautela

• Problemas de arredondamento: DOUBLE usa matemática de ponto flutuante, o que pode introduzir erros de arredondamento. Operações como 0,1 0,2 podem resultar em 0,30000000000000004.
• Perda potencial de precisão: Embora seja improvável que ocorra uma perda de precisão no cenário determinado, continua sendo uma possibilidade teórica.

Conclusão

No contexto do cenário específico, os argumentos contra a conversão de DOUBLE em DECIMAL superam aqueles a favor. A ausência de operações aritméticas SQL, precisão suficiente e histórico comprovado sugerem que os riscos de perda de precisão são mínimos. No entanto, é importante observar que para cálculos monetários de alta precisão ou em bancos de dados sujeitos a extensas operações aritméticas SQL, DECIMAL pode ser um tipo de dados mais adequado, apesar de seu potencial para maiores requisitos de espaço de armazenamento.