tipo de dato

[gnzsoloyo]

Lo que te confiene es definirlo como FLOAT o DOUBLE, ya que cuando manejas valores monetarios el problema no está en los decimales sino en los redondeos que se hace y que en su acumulación pueden representar cifras siderales.

Me explico: Si quisieras recortar el quinto decimal y transferirlo a otra variable, en un balance de cuentas de ventas, podría parecer una nimiedad (es un diezmilésimo), pero imagínate el efecto en el balance de una empresa que realiza 120.000 transacciones diarias (no hablemos las que hace eso en un minuto): El resultado sería la acumulación de 12 unidades monetarias por cada día... es decir, alquien se está quedando con 360 unidades monetarias en un mes, y que pertenecen a la empresa. No es una exageración, desde hace años las empresas saben que ese tipo de fraudes son posibles, cuando los sistemas no calculan bien las fracciones por detrás del máximo de decimales representables. Es una historia que viene desde la época de los maiframes de los años 50 y 60...

En definitiva esto se soluciona de una forma simple:
1. Los almacenamientos se hacen como DOUBLES o FLOAT por su mayor precisión (técnicamente hablando el tipo CURRENCY en algunos DBMS es un REAL, DOUBLE o FLOAT de la máxima precisión del sistema).
2. Las representaciones de los datos para las consultas se hacen con DECIMAL(X,2), siendo X la cantidad de decimales enteros a representar en el sistema. Toda otra solución es sospechosa en una auditoría...
No te olvides nunca que lo que debes representar es lo que el usuario debe ver, pero eso no quiere decir que eso es lo que se deba almacenar (un ejemplo sería que las SUMAS de una factura no se almacenan, se almacenan los valores que se sumarán; los valores calculables generan almacenamiento inútil y ocupan espacio).