DOUBLE против DECIMAL в MySQL: возвращение к дебатам о точности

Распространено мнение, что DOUBLE следует избегать при хранении денежных значений в базах данных MySQL из-за потенциальных проблем с точностью. Однако практический сценарий вызывает вопросы об обоснованности этой рекомендации.

Сочетание проблем точности с практическими соображениями

Данный сценарий включает в себя устаревшую систему с многочисленными столбцами DOUBLE для хранение денег. Несмотря на отсутствие арифметических операций SQL, опасения связаны с возможной потерей точности во время хранения и извлечения.

Аргументы против преобразования

• Нет побочные эффекты: Несмотря на шесть лет использования, ошибок, связанных с точностью, обнаружено не было.
• Достаточная точность: 15-значная точность DOUBLE соответствует требуемой десятичной точности 2–8. цифры.
• Внешние вычисления: Денежные вычисления выполняются в Java с использованием BigDecimal, что сводит к минимуму влияние форматирования данных MySQL.

Аргументы для осторожности

• Проблемы округления: DOUBLE использует математические вычисления с плавающей запятой, что может привести к ошибкам округления. Такие операции, как 0.1 0.2, могут привести к 0.30000000000000004.
• Потенциальная потеря точности: Хотя маловероятно, что потеря точности произойдет в данном сценарии, это остается теоретической возможностью.

Вывод

В контексте конкретного сценария аргументы против преобразования DOUBLE в DECIMAL перевешивают аргументы за него. Отсутствие арифметических операций SQL, достаточная точность и проверенная репутация позволяют предположить, что риски потери точности минимальны. Однако важно отметить, что для высокоточных денежных вычислений или в базах данных, подверженных обширным арифметическим операциям SQL, DECIMAL может быть более подходящим типом данных, несмотря на его потенциал для увеличения требований к пространству для хранения.