¿Debería elegir los tipos de datos DINERO o DECIMAL (x, y) en SQL Server?

Tengo curiosidad por saber si existe o no una diferencia real entre el moneytipo de datos y algo parecido decimal(19,4)(que es lo que el dinero usa internamente, creo).

Soy consciente de que moneyes específico de SQL Server. Quiero saber si hay una razón convincente para elegir uno sobre el otro; la mayoría de las muestras de SQL Server (por ejemplo, la base de datos AdventureWorks) usan moneyy no decimalpara cosas como información de precios.

¿Debo seguir usando el tipo de datos de dinero, o hay un beneficio al usar decimal en su lugar? El dinero tiene menos caracteres para escribir, pero esa no es una razón válida :)

Nunca deberías usar dinero. No es preciso, y es pura basura; siempre use decimal / numérico.

Ejecute esto para ver a qué me refiero:

DECLARE
    @mon1 MONEY,
    @mon2 MONEY,
    @mon3 MONEY,
    @mon4 MONEY,
    @num1 DECIMAL(19,4),
    @num2 DECIMAL(19,4),
    @num3 DECIMAL(19,4),
    @num4 DECIMAL(19,4)

    SELECT
    @mon1 = 100, @mon2 = 339, @mon3 = 10000,
    @num1 = 100, @num2 = 339, @num3 = 10000

    SET @mon4 = @mon1/@mon2*@mon3
    SET @num4 = @num1/@num2*@num3

    SELECT @mon4 AS moneyresult,
    @num4 AS numericresult

Salida: 2949.0000 2949.8525

Para algunas de las personas que dijeron que no divide dinero por dinero:

Aquí está una de mis consultas para calcular correlaciones, y cambiar eso a dinero da resultados incorrectos.

select t1.index_id,t2.index_id,(avg(t1.monret*t2.monret)
    -(avg(t1.monret) * avg(t2.monret)))
            /((sqrt(avg(square(t1.monret)) - square(avg(t1.monret))))
            *(sqrt(avg(square(t2.monret)) - square(avg(t2.monret))))),
current_timestamp,@MaxDate
            from Table1 t1  join Table1 t2  on t1.Date = traDate
            group by t1.index_id,t2.index_id

SQLMenace dijo que el dinero es inexacto. ¡Pero no multiplica / divide dinero por dinero! ¿Cuánto es 3 dólares por 50 centavos? 150 centavos de dólar? Multiplicas / divides dinero por escalares, que deben ser decimales.

DECLARE
@mon1 MONEY,
@mon4 MONEY,
@num1 DECIMAL(19,4),
@num2 DECIMAL(19,4),
@num3 DECIMAL(19,4),
@num4 DECIMAL(19,4)

SELECT
@mon1 = 100,
@num1 = 100, @num2 = 339, @num3 = 10000

SET @mon4 = @mon1/@num2*@num3
SET @num4 = @num1/@num2*@num3

SELECT @mon4 AS moneyresult,
@num4 AS numericresult

Resultados en el resultado correcto:

resultado numérico
--------------------- ----------------------------- ----------
2949.8525 2949.8525

moneyes bueno siempre que no necesite más de 4 dígitos decimales y se asegure de que sus escalares, que no representan dinero, sean decimals.

Todo es peligroso si no sabes lo que estás haciendo.

Incluso los tipos decimales de alta precisión no pueden salvar el día:

declare @num1 numeric(38,22)
declare @num2 numeric(38,22)
set @num1 = .0000006
set @num2 = 1.0
select @num1 * @num2 * 1000000

1.000000 <- Debe ser 0.6000000

Los moneytipos son enteros.

Las representaciones de texto de smallmoneyy decimal(10,4)pueden parecerse, pero eso no las hace intercambiables. ¿Te estremeces cuando ves las fechas almacenadas como varchar(10)? Esto es lo mismo.

Detrás de escena, money/ smallmoneyson solo a bigint/ int El punto decimal en la representación de texto de moneyes pelusa visual, al igual que los guiones en una fecha aaaa-mm-dd. SQL en realidad no los almacena internamente.

Con respecto a decimalvs money, elija lo que sea apropiado para sus necesidades. Los moneytipos existen porque almacenar valores contables como múltiplos enteros de 1/10000 de unidad es muy común. Además, si se trata de dinero real y cálculos más allá de la simple suma y resta, ¡no debería hacerlo a nivel de base de datos! Hágalo a nivel de aplicación con una biblioteca que admita el redondeo bancario (IEEE 754)

Me doy cuenta de que WayneM ha declarado que sabe que el dinero es específico de SQL Server. Sin embargo, está preguntando si hay alguna razón para usar el dinero en lugar del decimal o viceversa, y creo que aún se debe indicar una razón obvia y que usar el decimal significa que es una cosa menos de la que preocuparse si alguna vez tiene que cambiar su DBMS - Que puede suceder.

¡Haga que sus sistemas sean lo más flexibles posible!

Bueno, me gusta MONEY! Es un byte más barato que DECIMAL, y los cálculos se realizan más rápido porque (debajo de las cubiertas) las operaciones de suma y resta son esencialmente operaciones enteras. El ejemplo de @ SQLMenace, que es una gran advertencia para los que no lo saben, podría aplicarse igualmente a los INTegers, donde el resultado sería cero. Pero esa no es razón para no usar números enteros, cuando corresponda .

Por lo tanto, es perfectamente 'seguro' y apropiado usarlo MONEYcuando se trata de MONEYeso y usarlo de acuerdo con las reglas matemáticas que sigue (igual que INTeger).

¿Hubiera sido mejor si SQL Server promoviera la división y la multiplicación de MONEY's en DECIMALs (o FLOATs)? Posiblemente, pero no eligieron hacer esto; ni eligieron promover INTegers a FLOATs al dividirlos.

MONEYno tiene problemas de precisión; eso DECIMALde tener un tipo intermedio más grande usado durante los cálculos es solo una 'característica' de usar ese tipo (y en realidad no estoy seguro de hasta qué punto se extiende esa 'característica').

Para responder a la pregunta específica, ¿una "razón convincente"? Bueno, si desea un rendimiento máximo absoluto en un lugar SUM(x)donde xpodría ser DECIMALo MONEY, entonces MONEYtendrá una ventaja.

Además, no olvide que es un primo más pequeño, de solo SMALLMONEY4 bytes, pero tiene un máximo de 214,748.3647, que es bastante pequeño para el dinero, y por lo tanto no suele ser una buena opción.

Para probar el punto usando tipos intermedios más grandes, si asigna el intermedio explícitamente a una variable, DECIMALsufre el mismo problema:

declare @a decimal(19,4)
declare @b decimal(19,4)
declare @c decimal(19,4)
declare @d decimal(19,4)

select @a = 100, @b = 339, @c = 10000

set @d = @a/@b

set @d = @d*@c

select @d

Produce 2950.0000(bueno, al menos DECIMALredondeado en lugar de MONEYtruncado, igual que un entero).

Acabamos de encontrarnos con un problema muy similar y ahora soy un +1 por nunca usar Money, excepto en la presentación de nivel superior. Tenemos varias tablas (efectivamente un comprobante de venta y una factura de venta), cada una de las cuales contiene uno o más campos de Dinero por razones históricas, y necesitamos realizar un cálculo prorrateado para determinar cuánto del Impuesto total de la factura es relevante para cada línea en el comprobante de venta. Nuestro cálculo es

vat proportion = total invoice vat x (voucher line value / total invoice value)

Esto da como resultado un cálculo de dinero / dinero del mundo real que causa errores de escala en la parte de división, que luego se multiplica en una proporción de IVA incorrecta. Cuando estos valores se agregan posteriormente, terminamos con una suma de las proporciones de iva que no se suman al valor total de la factura. Si cualquiera de los valores entre paréntesis hubiera sido un decimal (estoy a punto de lanzar uno de ellos como tal), la proporción del iva sería correcta.

Cuando los corchetes no estaban allí originalmente, esto solía funcionar, supongo que debido a los valores más grandes involucrados, efectivamente estaba simulando una escala más alta. Agregamos los corchetes porque estaba haciendo la multiplicación primero, lo que en algunos casos raros sopló la precisión disponible para el cálculo, pero esto ahora ha causado este error mucho más común.

Como contrapunto al impulso general de las otras respuestas. Vea los muchos beneficios del dinero ... ¡Tipo de datos! en la Guía de SQLCAT para el motor relacional

Específicamente, señalaría lo siguiente

Trabajando en implementaciones de clientes, encontramos algunos números de rendimiento interesantes relacionados con el tipo de datos de dinero. Por ejemplo, cuando Analysis Services se configuró en el tipo de datos de moneda (del doble) para que coincida con el tipo de datos de dinero de SQL Server, hubo una mejora del 13% en la velocidad de procesamiento (filas / seg). Para obtener un rendimiento más rápido dentro de SQL Server Integration Services (SSIS) para cargar 1.18 TB en menos de treinta minutos, como se señaló en SSIS 2008 - rendimiento ETL récord mundial, se observó que al cambiar las cuatro columnas decimales (9,2) con un tamaño de 5 bytes en la tabla TPC-H LINEITEM a dinero (8 bytes) mejoraron la velocidad de inserción masiva en un 20% ... La razón de la mejora del rendimiento se debe al protocolo de flujo de datos tabulares (TDS) de SQL Server, que tiene el principio de diseño clave para transferir datos en forma binaria compacta y lo más cerca posible del formato de almacenamiento interno de SQL Server. Empíricamente, esto se observó durante el SSIS 2008: prueba de rendimiento ETL récord mundial con Kernrate; el protocolo cayó significativamente cuando el tipo de datos se cambió a dinero desde decimal. Esto hace que la transferencia de datos sea lo más eficiente posible. Un tipo de datos complejo necesita análisis y ciclos de CPU adicionales para manejar que un tipo de ancho fijo.

Entonces la respuesta a la pregunta es "depende". Debe tener más cuidado con ciertas operaciones aritméticas para preservar la precisión, pero puede encontrar que las consideraciones de rendimiento hacen que valga la pena.

Quiero dar una visión diferente de DINERO versus NUMÉRICO, basándome en gran medida en mi propia experiencia y experiencia ... Mi punto de vista aquí es DINERO, porque he trabajado con él durante mucho tiempo y nunca utilicé mucho NUMÉRICO. .

DINERO Pro:

• Tipo de datos nativos . Utiliza un tipo de datos nativo ( entero ) igual que un registro de CPU (32 o 64 bits), por lo que el cálculo no necesita una sobrecarga innecesaria, por lo que es más pequeño y más rápido ... DINERO necesita 8 bytes y NUMÉRICO (19, 4 ) necesita 9 bytes (12.5% ​​más grande) ...

  El DINERO es más rápido siempre que se use para lo que estaba destinado (como dinero). ¿Qué rápido? Mi simple SUMprueba en 1 millón de datos muestra que el DINERO es 275 ms y NUMÉRICO 517 ms ... Eso es casi el doble de rápido ... ¿Por qué la prueba SUMA? Ver siguiente punto Pro

• Lo mejor por dinero . El DINERO es mejor para almacenar dinero y realizar operaciones, por ejemplo, en contabilidad. Un solo informe puede ejecutar millones de adiciones (SUM) y algunas multiplicaciones después de que se realiza la operación SUM. Para aplicaciones de contabilidad muy grandes es casi el doble de rápido , y es extremadamente significativo ...
• Baja precisión de dinero . El dinero en la vida real no necesita ser muy preciso. Quiero decir, a muchas personas les puede interesar alrededor de 1 centavo de dólar, pero ¿qué tal 0.01 centavo de dólar? De hecho, en mi país, a los bancos ya no les importan los centavos (dígito después de una coma decimal); No sé sobre el banco estadounidense u otro país ...

DINERO Con:

• La precisión limitada . El DINERO solo tiene una precisión de cuatro dígitos (después de la coma), por lo que debe convertirse antes de realizar operaciones como la división ... Pero, de nuevo money, no necesita ser tan preciso y debe usarse como dinero, no solo para número...

Pero ... Grande, pero aquí incluso su aplicación involucra dinero real, pero no la use en muchas operaciones de SUM, como en contabilidad. Si usa muchas divisiones y multiplicaciones, entonces no debería usar DINERO ...

Todas las publicaciones anteriores aportan puntos válidos, pero algunas no responden la pregunta con precisión.

La pregunta es: ¿por qué alguien preferiría el dinero cuando ya sabemos que es un tipo de datos menos preciso y puede causar errores si se usa en cálculos complejos?

Usas dinero cuando no haces cálculos complejos y puedes cambiar esta precisión por otras necesidades.

Por ejemplo, cuando no tiene que hacer esos cálculos y necesita importar datos de cadenas de texto de moneda válidas. Esta conversión automática solo funciona con el tipo de datos DINERO:

SELECT CONVERT(MONEY, '$1,000.68')

Sé que puedes hacer tu propia rutina de importación. Pero a veces no desea volver a crear una rutina de importación con formatos locales específicos en todo el mundo.

Otro ejemplo, cuando no tiene que hacer esos cálculos (solo necesita almacenar un valor) y necesita guardar 1 byte (el dinero toma 8 bytes y el decimal (19,4) toma 9 bytes). En algunas aplicaciones (CPU rápida, RAM grande, IO lenta), como leer una gran cantidad de datos, esto también puede ser más rápido.

No debe usar dinero cuando necesita hacer multiplicaciones / divisiones en el valor. El dinero se almacena de la misma manera que se almacena un número entero, mientras que el decimal se almacena como un punto decimal y dígitos decimales. Esto significa que el dinero disminuirá la precisión en la mayoría de los casos, mientras que el decimal solo lo hará cuando se vuelva a convertir a su escala original. El dinero es un punto fijo, por lo que su escala no cambia durante los cálculos. Sin embargo, debido a que es un punto fijo cuando se imprime como una cadena decimal (a diferencia de como una posición fija en una cadena de base 2), los valores hasta la escala de 4 se representan exactamente. Entonces, para sumar y restar, el dinero está bien.

Un decimal se representa en la base 10 internamente y, por lo tanto, la posición del punto decimal también se basa en el número de la base 10. Lo que hace que su parte fraccional represente exactamente su valor, al igual que con el dinero. La diferencia es que los valores intermedios de decimal pueden mantener una precisión de hasta 38 dígitos.

Con un número de coma flotante, el valor se almacena en binario como si fuera un número entero, y la posición del punto decimal (o binario, ejem) es relativa a los bits que representan el número. Debido a que es un punto decimal binario, los números de base 10 pierden precisión justo después del punto decimal. 1 / 5th, o 0.2, no se pueden representar con precisión de esta manera. Ni el dinero ni el decimal sufren esta limitación.

Es bastante fácil convertir dinero a decimal, realizar los cálculos y luego almacenar el valor resultante nuevamente en un campo o variable de dinero.

Desde mi POV, quiero que las cosas que suceden con los números sucedan sin tener que pensar demasiado en ellas. Si todos los cálculos se van a convertir a decimal, entonces para mí solo querría usar decimal. Guardaría el campo de dinero para mostrar.

En cuanto al tamaño, no veo suficiente diferencia para cambiar de opinión. El dinero toma de 4 a 8 bytes, mientras que el decimal puede ser 5, 9, 13 y 17. Los 9 bytes pueden cubrir todo el rango que pueden tener los 8 bytes de dinero. En cuanto al índice (comparar y buscar debe ser comparable).

Encontré una razón sobre el uso de decimal sobre dinero en materia de precisión.

DECLARE @dOne   DECIMAL(19,4),
        @dThree DECIMAL(19,4),
        @mOne   MONEY,
        @mThree MONEY,
        @fOne   FLOAT,
        @fThree FLOAT

 SELECT @dOne   = 1,
        @dThree = 3,    
        @mOne   = 1,
        @mThree = 3,    
        @fOne   = 1,
        @fThree = 3

 SELECT (@dOne/@dThree)*@dThree AS DecimalResult,
        (@mOne/@mThree)*@mThree AS MoneyResult,
        (@fOne/@fThree)*@fThree AS FloatResult

Resultado decimal> 1.000000

MoneyResult> 0.9999

FloatResult> 1

Solo pruébalo y toma tu decisión.

Acabo de ver esta entrada de blog: Money vs. Decimal en SQL Server .

Lo que básicamente dice que el dinero tiene un problema de precisión ...

declare @m money
declare @d decimal(9,2)

set @m = 19.34
set @d = 19.34

select (@m/1000)*1000
select (@d/1000)*1000

Para el moneytipo, obtendrá 19.30 en lugar de 19.34. No estoy seguro de si existe un escenario de aplicación que divide el dinero en 1000 partes para el cálculo, pero este ejemplo expone algunas limitaciones.