Al desarrollar sistemas de pago o comercio electrónico, ¿ha pensado alguna vez en utilizar FLOAT o DOUBLE para los campos de importe de la base de datos?
Si es así, ¡deténgase ahí mismo! Su sistema podría estar perdiendo dinero en secreto.
¿Por qué están prohibidos los números de punto flotante en los sistemas financieros? Un error de precisión aparentemente insignificante, acumulado a lo largo de volúmenes de transacciones masivos y del tiempo, podría provocar desastres irreversibles.
Entonces, ¿qué deberíamos usar exactamente para almacenar dinero?
¿Por qué FLOAT es tóxico para los sistemas financieros?
En el mundo informático, los números se representan en binario. FLOAT (números de punto flotante), al representar ciertas fracciones decimales, es en realidad una “aproximación”. Es como intentar cortar un pastel delicado con una motosierra rústica; no importa el cuidado que tenga, siempre caerán algunas migas de los bordes.
El ejemplo clásico es: 0.1 + 0.2 a menudo no es igual a 0.3 en una computadora. Si está procesando millones de transacciones, estos diminutos errores de “0.00000000000000004” se acumularán y los libros de contabilidad nunca cuadrarán. Recuerde:
Cuando se trata de dinero, cualquier “aproximación” es un desastre.
El libro de contabilidad preciso del contador: las ventajas de DECIMAL
Si desea una solución exacta donde “lo que ve es lo que obtiene”, DECIMAL es el número de coma fija nativo de la base de datos y el estándar de la industria.
DECIMAL es como el libro de contabilidad exquisito en manos de un contador; separa con precisión números enteros y decimales, asegurando que 0.1 + 0.2 sea absolutamente igual a 0.3.
La proporción dorada de la industria: DECIMAL(19, 4)
Generalmente recomendamos usar DECIMAL(19, 4):
- 19: Representa una capacidad total de 19 dígitos (precisión).
- 4: Denota retener 4 dígitos después del punto decimal.
¿Por qué conservar 4 decimales? Porque durante los cálculos de tasas de interés, tasas de impuestos o tipos de cambio, los pasos intermedios a menudo arrojan más de 2 decimales. Reservar 2 dígitos adicionales de amortiguación mejora la precisión del cálculo, y simplemente puede redondear según las necesidades comerciales al final.
¡Esta capacidad es incluso lo suficientemente grande como para comprar el PIB total de varias Tierras!
¿Es suficiente para los escenarios financieros del mundo real?
Tomando DECIMAL(19, 4) como ejemplo:
- Dígitos enteros: 15 dígitos
- Monto máximo: 999,999,999,999,999
- Conversión a USD: Aprox. 999 billones de dólares
| Referencia | Importe |
|---|---|
| PIB de EE. UU. | Aprox. 27 billones de dólares |
| PIB mundial total | Aprox. 105 billones de dólares |
| Riqueza mundial total | Aprox. 454 billones de dólares |
DECIMAL(19, 4) puede acomodar números que superan con creces la riqueza global total, y es perfectamente suficiente para la gran mayoría de los sistemas financieros.
Límites máximos de precisión DECIMAL admitidos por las principales bases de datos
| Base de datos | Precisión máxima |
|---|---|
| MySQL / MariaDB | 65 |
| PostgreSQL | 131072 (dígitos enteros) + 16383 (dígitos decimales) |
| SQL Server | 38 |
| Oracle | 38 |
La máquina de fichas recreativa: el método de la unidad más pequeña BIGINT
Si busca un rendimiento máximo o si su sistema tiene demandas de concurrencia ultra altas como Stripe o Alipay, entonces BIGINT (método de almacenamiento de enteros) podría ser su mejor opción.
Este enfoque es como la máquina de fichas de una sala de juegos: no importa cuánto dinero introduzca, la máquina lo convierte en la “unidad más pequeña” para su almacenamiento. Por ejemplo:
- $100.50 USD → Almacenado como
10050(centavos) - 100 TWD → Almacenado como
100(dólares)
¿Por qué elegir BIGINT?
| Razón | Descripción |
|---|---|
| Velocidad ultrarrápida | La suma y resta de números enteros son especialidades de la CPU; el rendimiento computacional suele ser mucho más rápido que DECIMAL. |
| Eficiencia de espacio | Asignación fija de 8 bytes, muy adecuada para bases de datos muy grandes. |
Sin embargo, el inconveniente es una peor legibilidad. Cuando abre la base de datos y ve 10050, debe dividirlo automáticamente por 100 en su cabeza (o en su código).
El enfrentamiento definitivo: ¿Cómo elegir?
Para decidir cuál usar, podemos considerar “frecuencia de consulta” y “escala del sistema”:
| Dimensión de comparación | DECIMAL | BIGINT |
|---|---|---|
| Legibilidad | Excelente (leer números directamente) | Peor (requiere conversión manual) |
| Velocidad de cálculo | Regular | Extremadamente rápida |
| Escenarios aplicables | ERP, sistemas financieros internos, comercio electrónico general | Negociación de alta frecuencia, microservicios ultragrandes, API estilo Stripe |
Recomendaciones pragmáticas
| Escenario aplicable | Campo recomendado |
|---|---|
| Comercio electrónico general, sistemas de información internos corporativos, donde los contadores necesitan ejecutar SQL directamente para auditorías | DECIMAL(19, 4) |
| Sistemas de comercio de alta frecuencia o requisitos de escalabilidad extrema | BIGINT |
Resumen
En resumen, no importa cuál elija, ¡está absoluta y permanentemente prohibido usar FLOAT para almacenar dinero! La elección del tipo de campo correcto garantiza que su sistema siga siendo sólido como una roca en los cálculos financieros.