c# - net - ¿Qué tipo de campo de SQL Server es mejor para almacenar valores de precios?

insertar imagen sql server

Question

Me pregunto cuál es el mejor tipo para un campo de precios en SQL Server para una estructura tipo tienda.

En cuanto a esta visión general , tenemos tipos de datos llamados money , smallmoney , luego tenemos decimal / numérico y finalmente float y real .

Nombre, memoria / uso del disco y rangos de valores:

• Dinero: 8 bytes (valores: -922,337,203,685,477.5808 a +922,337,203,685,477.5807)
• Smallmoney: 4 bytes (valores: -214,748.3648 a +214,748.3647)
• Decimal: 9 [predeterminado, mín. 5] bytes (valores: -10 ^ 38 +1 a 10 ^ 38 -1)
• Flotante: 8 bytes (valores: -1.79E + 308 a 1.79E + 308)
• Real: 4 bytes (valores: -3.40E + 38 a 3.40E + 38)

¿Es realmente inteligente almacenar valores de precios en esos tipos? ¿Qué tal, por ejemplo? ¿EN T?

• Int: 4 bytes (valores: -2,147,483,648 a 2,147,483,647)

Digamos que una tienda usa dólares, tienen centavos, pero no veo que los precios sean de $ 49.2142342 por lo que el uso de muchos decimales que muestran centavos parece desperdiciar el ancho de banda de SQL. En segundo lugar, la mayoría de las tiendas no mostrarían precios cercanos a los 200.000.000 (al menos no en las tiendas web normales, a menos que alguien intente venderme una famosa torre en París).

Entonces, ¿por qué no ir por un int?

Un int es rápido, solo tiene 4 bytes y puede hacer fácilmente decimales, guardando valores en centavos en lugar de dólares y luego divide cuando presente los valores.

El otro enfoque sería usar smallmoney, que también tiene 4 bytes, pero esto requerirá que la parte matemática de la CPU haga el cálculo, mientras que Int es potencia entera ... en el lado negativo necesitarás dividir cada resultado.

¿Hay algún problema relacionado con la "moneda" con la configuración regional al usar los campos smallmoney / money? ¿Qué transferirán estos también en C # /. NET?

Cualquier pros / contras? Ir por precios enteros o smallmoney o algún otro?

¿Qué dice tu experiencia?

Answer 1

En mi aplicación de casa de empeños, los operadores de casas de empeños prestan de $ 5.00 a $ 10.000. Cuando calculan el monto del préstamo, lo redondean al dólar más cercano para evitar tener que pagar centavos (lo mismo aplica para los pagos de intereses). Cuando el monto del préstamo sea superior a $ 50.00 lo redondearán a los $ 5,00 más cercanos (es decir, $ 50, $ 55, $ 60 ...), nuevamente para minimizar el quedarse sin billetes de un dólar. Por lo tanto, uso DECIMAL (7,2) para transaction.calculated_loan_amount y DECIMAL (5,0) para transaction.loan_amount. La aplicación calcula el monto del préstamo al centavo y coloca esa cantidad en loan_amount, donde se redondea al dólar más cercano cuando está por debajo de $ 50 o al valor más cercano de $ 5,00 cuando es mayor.

Answer 2

Los tipos de datos SQL money y smallmoney resuelven en tipo decimal c #:

http://msdn.microsoft.com/en-us/library/system.data.sqltypes.sqlmoney(v=VS.71).aspx

Así que estoy pensando que también podrías elegir el decimal . Personalmente he estado usando el double toda mi vida trabajando en la industria financiera y no he tenido problemas de rendimiento, etc. En realidad, he descubierto que para ciertos cálculos, etc., tener un tipo de datos más grande permite un mayor grado de precisión .

Answer 3

Personalmente, usaría smallmoney o dinero para almacenar precios de tienda.

Usar int agrega complejidad a otra parte.

Y 200 millones es un precio perfectamente válido en won coreano o rupias indonesias también ...

Answer 4

USE NUMERIC / DECIMAL. Evita el dinero / SMALLMONEY. Aquí hay un ejemplo de por qué . Tarde o temprano, los tipos MONEY / SMALLMONEY probablemente lo decepcionarán debido a errores de redondeo. Los tipos de dinero son completamente redundantes y no logran nada útil; una cantidad de moneda es simplemente otro número decimal como cualquier otro.

Por último, los tipos MONEY / SMALLMONEY son propiedad de Microsoft. NUMERIC / DECIMAL son parte del estándar SQL. Son utilizados, reconocidos y comprendidos por más personas y son compatibles con la mayoría de los DBMS y otros softwares.

Answer 5

Utilice el tipo de datos Money si está almacenando dinero (a menos que modele enormes cantidades de dinero como la deuda nacional), ya que evita problemas de precisión / redondeo.

Los muchos beneficios del dinero ... ¡tipo de datos!

Answer 6

Yo buscaría el tipo de datos Money. Invididually no puede exceder el valor en Smallmoney, pero sería fácil que varios artículos lo excedan.

Answer 7

Si está absolutamente seguro de que sus números siempre se mantendrán dentro del rango de smallmoney , smallmoney y ahorrará algunos bytes. De lo contrario, usaría money . Pero recuerde, el almacenamiento es barato en estos días. Los 4 bytes adicionales en más de 100 millones de registros aún son menos de medio GB. Sin embargo, como señala @marc_s, usar smallmoney si puede reducirá la huella de memoria del servidor SQL.

Para smallmoney , si puedes salirte con la smallmoney , hazlo. Si crees que puedes exceder el límite máximo, usa money .

Pero no use un tipo de decimal flotante o obtendrá problemas de redondeo y comenzará a perder u obtener centavos aleatorios, a menos que los maneje adecuadamente.

Mi argumento en contra de usar int : ¿Por qué reinventar la rueda almacenando un int y luego tener que recordar dividir entre 100 (10000) para recuperar el valor y multiplicarlo cuando va a almacenar el valor? Mi entendimiento es que los tipos de dinero usan un int o long como el tipo de almacenamiento subyacente de todos modos.

En cuanto al tipo de datos correspondiente en .NET, será decimal (lo que también evitará problemas de redondeo en su código C #).