Tipo de dato para PRECIO

[hmv]

Hola a todos,

En que tipo de dato de mysql puedo almacenar en el campo PRECIO
ej,

1.339,28

Gracias

[jurena]

Tienes que distinguir el tipo de dato (yo te recomiendo DECIMAL(); también podría ser FLOAT), del formato de entrada y salida: el formato de entrada de datos en la base en un campo de ese tipo obliga a separar el decimal con punto, pero no marca los miles, es decir, tú escribes 1339.28; el de salida puede modificarse mediante la función FORMAT() de MySQL, aunque para lo que buscas, puedes usar funciones de programa. Por ej., si usas PHP, yo te aconsejaría usar number_format(). Mira en el manual de PHP, si es tu caso. Echa un vistazo a esas funciones.

[morior]

Usa un campo FLOAT. Luego cuando lo saques de la base de datos, le aplicas number format como comenta el compañero.

Código PHP:

<?
 
$precio = 100234.55;
 
 
echo number_format($precio,2);//EL dos indica los números de decimales que tiene el número.
 
?>
 

[gnzsoloyo]

Lo que el manual de referencia aconseja no es el FLOAT o el DOUBLE, sino el DECIMAL. Esto es así porque lo que guarda el FLOAT es un número de punto flotante que representa el valor más cercano al indicado, pero tiene un defecto (ínfimo) que se manifiesta al hacer cierto ripo de cálculos.
Yendo al manual de referencia:

FLOAT:

El tipo FLOAT se usa para representar tipos numéricos aproximados. El estándar SQL permite una especificación opcional de la precisión (pero no del rango del exponente) en bits a continación de la palabra clave FLOAT entre paréntesis. La implementación de MySQL soporta esta especificación opcional de precisión, pero el valor de precisión se usa sólo para determinar el tamaño de almacenamiento. Una precisión de 0 a 23 resulta en una columna de precisión simple de cuatro bytes de tamaño FLOAT . Una precisión de 24 a 53 resulta en una columna de doble precisión de ocho bytes de tamaño DOUBLE .

DECIMAL:

Los tipos DECIMAL y NUMERIC se implementan como el mismo tipo en MySQL. Se usan para guardar valores para los que es importante preservar una precisión exacta, por ejemplo con datos monetarios.

[javihd]

Hola,

Yo tengo un problema parecido,

le pongo DECIMAL(6,3)

pero luego hago un select de precio y solo me muestra los enteros, no hay ni rastro de los decimales.

¿que puede ser?

gracias y saludos.

PD: Lo hago en Ubuntu y pasando los datos desde Calc a Base. todo bien menos eso.

[javihd]

perdón,

he intentado de nuevo con DECIMAL(6,2) y me aparece así:

155.00

está añadiendo 2 ceros despues del punto, pero no está del todo bien, porque debería quedar así:

155.43


¿por qué? ¿qué me falta añadir?

PD: Cuando inicio la transferencia de datos de Calc a Base. OpenOffice Base me dice lo siguiente:

'' Advertencia! - Data truncation: Out of range value for column 'precio' at row 1
¿Desea continuar de todos modos? ''

[javihd]

bueno ya lo he solucionado.

Gracias de todas formas.

[ozkar911]

Iniciado por javihd

bueno ya lo he solucionado.

Gracias de todas formas.

Yo tengo el mismo problema.
Podrias poner como lo solucionastes?
cual es el mejor tipo de datos para precios?

[pamda]

Iniciado por ozkar911

Yo tengo el mismo problema.
Podrias poner como lo solucionastes?
cual es el mejor tipo de datos para precios?

y segun nuestro amigo @gnzsoloyo... en su respuesta que esta más arriba, es eso lo que recomienda...
http://www.forosdelweb.com/f86/tipo-dato-para-precio-776254/#post3271992

[enridp]

y por qué no usar solo INT y guardar centavos en lugar de pesos (o dolares)?
De hecho estuve buscando bastante en internet y no pude encontrar cual de las dos soluciones (sobre todo en cuanto a performance) es mejor.

Ustedes que opinan?
DECIMAL o INT para precios?

PD: en cuanto a performance me refiero sobre a todo a consultas con WHERE y ORDER BY sobre el campo precio.

[gnzsoloyo]

¿Qué prefieres? ¿Usar 8 bytes para guardar precios o usar de 12 a 16?

No le des vuelta al asunto: Si en todos los sistemas contables basados en MySQL se usa DECIMAL, y eso es lo que MySQL recomienda, ¿para qué vas a inventar la rueda de nuevo?

Usa DECIMAL.

En cuanto a performance, la cosa no importa, porque los valores se coparan como binarios y no como cifras... Es indistinto. El problema es de eficiencia de datos.

[enridp]

No es por reinventar nada, en muchos sitios recomendaban como alternativa usar un INT (a veces un MEDIUMINT de acuerdo a la cant. de digitos).

Sobre todo por preguntas donde tenian probelmas con los puntos, las comas, los decimales, etc.
Supongo era por mal uso de las consultas.
Pero me surgió la duda, y crei que tal vez un nro entero tendría ventajas en cuanto a las operaciones de busqueda, ordenación, comparación, calculos de máx,min, etc.

Pero si la performance de estas operaciones es la misma y un DECIMAL ocupa menos entonces no hay mucho que pensar supongo.