El mejor tipo de datos para almacenar valores monetarios en MySQL

Quiero almacenar muchos registros en una base de datos MySQL. Todos ellos contienen valores monetarios. Pero no sé cuántos dígitos se insertarán para cada uno.
¿Qué tipo de datos debo usar para este propósito?
VARCHAR o INT (u otros tipos de datos numéricos)?

Dado que el dinero necesita una representación exacta, no use tipos de datos que sean solo aproximados float. Puede usar un tipo de datos numéricos de punto fijo para ese tipo de

decimal(15,2)

• 15 es la precisión (longitud total del valor, incluidos los decimales)
• 2 es el número de dígitos después del punto decimal

Ver tipos numéricos de MySQL :

Estos tipos se utilizan cuando es importante preservar la precisión exacta, por ejemplo, con datos monetarios .

Puedes usar DECIMALo NUMERICambos son iguales

Los tipos DECIMAL y NUMERIC almacenan valores de datos numéricos exactos. Estos tipos se utilizan cuando es importante preservar la precisión exacta, por ejemplo, con datos monetarios. En MySQL, NUMERIC se implementa como DECIMAL, por lo que las siguientes observaciones sobre DECIMAL se aplican igualmente a NUMERIC. : MySQL

es decir DECIMAL(10,2)

Buena lectura

Prefiero usar BIGINTy almacenar los valores multiplicando por 100 , para que se convierta en entero.

Por ejemplo, para representar un valor de moneda de 93.49, el valor se almacenará como 9349, mientras se muestra el valor que podemos dividir por 100 y mostrar. Esto ocupará menos espacio de almacenamiento.

Precaución: la
mayoría de las veces no realizamos la currency * currencymultiplicación, en caso de que lo hagamos, dividimos el resultado entre 100 y almacenamos, para que vuelva a la precisión adecuada.

Depende de tu necesidad.

Por lo DECIMAL(10,2)general, usar es suficiente, pero si necesita valores un poco más precisos, puede establecerlos DECIMAL(10,4).

Si trabaja con grandes valores, reemplácelos 10por 19.

Si su aplicación necesita manejar valores monetarios de hasta un billón, esto debería funcionar: 13,2 Si necesita cumplir con los GAAP (Principios de contabilidad generalmente aceptados), use: 13,4

Por lo general, debe sumar sus valores monetarios en 13,4 antes de redondear la salida a 13,2.

De hecho, esto se basa en las preferencias del programador. Yo personalmente uso: numeric(15,4)para cumplir con los Principios de contabilidad generalmente aceptados ( GAAP ) .

Intenta usar

Decimal(19,4)

esto generalmente funciona con cualquier otro DB también

Nosotros usamos double.

*jadear*

¿Por qué?

Porque puede representar cualquier número de 15 dígitos sin restricciones sobre dónde está el punto decimal . ¡Todo por unos miserables 8 bytes!

Entonces puede representar:

• 0.123456789012345
• 123456789012345.0

... y cualquier cosa en el medio.

Esto es útil porque estamos tratando con monedas globales , ydouble podemos almacenar los diversos números de decimales que probablemente encontraremos.

Un solo doublecampo puede representar 999,999,999,999,999s en yenes japoneses, 9,999,999,999,999.99s en dólares estadounidenses e incluso 9,999,999.999999999s en bitcoins

Si intenta hacer lo mismo con decimal, necesita lo decimal(30, 15)que cuesta 14 bytes.

Advertencias

Por supuesto, el uso doubleno está exento de advertencias.

Sin embargo, no es una pérdida de precisión como algunos tienden a señalar. Aunque doublepuede no ser internamente exacto al sistema base 10 , podemos hacerlo exacto redondeando el valor que extraemos de la base de datos a sus decimales significativos. Si es necesario, eso es. (por ejemplo, si se va a generar y se requiere una representación de base 10).

Las advertencias son que, cada vez que realizamos operaciones aritméticas con él, necesitamos normalizar el resultado (redondeándolo a sus decimales significativos) antes de:

1. Realizando comparaciones en él.
2. Escribiéndolo nuevamente en la base de datos.

Otro tipo de advertencia es que, a diferencia de decimal(m, d)donde la base de datos evitará que los programas inserten un número con más de mdígitos, no existen tales validaciones double. Un programa podría insertar un valor ingresado por el usuario de 20 dígitos y terminará siendo registrado silenciosamente como una cantidad inexacta.

En el momento en que se hizo esta pregunta, nadie pensó en el precio de Bitcoin. En el caso de BTC, probablemente sea insuficiente para usar DECIMAL(15,2). Si el Bitcoin aumentará a $ 100,000 o más, necesitaremos al menos DECIMAL(18,9)admitir criptomonedas en nuestras aplicaciones.

DECIMAL(18,9)ocupa 12 bytes de espacio en MySQL ( 4 bytes por 9 dígitos ).

Almacenar dinero BIGINTmultiplicado por 100 o más con la razón de usar menos espacio de almacenamiento no tiene sentido en todas las situaciones "normales".

• Para mantenerse alineado con GAAP es suficiente almacenar monedas en DECIMAL(13,4)
• El manual de MySQL dice que necesita 4 bytes por cada 9 dígitos para almacenar DECIMAL.
  • https://dev.mysql.com/doc/refman/8.0/en/precision-math-decimal-characteristics.html
• DECIMAL(13,4) representa 9 dígitos + 4 dígitos de fracción (lugares decimales) => 4 + 2 bytes = 6 bytes
• comparar a 8 bytes necesarios para almacenar BIGINT.

Si se requiere cumplimiento de GAAP o necesita 4 decimales:

DECIMAL (13, 4) que admite un valor máximo de:

$ 999,999,999.9999

De lo contrario, si 2 decimales son suficientes: DECIMAL (13,2)

src: https://rietta.com/blog/best-data-types-for-currencymoney-in/

Multiplica 10000 y almacena como BIGINT, como "Moneda" en Visual Basic y Office. Ver https://msdn.microsoft.com/en-us/library/office/gg264338.aspx