SELECT SUM(monto) as total FROM DIARIO
pero hay un error ejemplo si en mi base mi numero esta asi... 1,500.00
la consulta solo me arroja 1...como se debe solucionar este detalle ...
18/08/2014, 13:04
| ||||
| ||||
| sumar con comas tengo la siguiente consulta SELECT SUM(monto) as total FROM DIARIO pero hay un error ejemplo si en mi base mi numero esta asi... 1,500.00 la consulta solo me arroja 1...como se debe solucionar este detalle ... |
|
18/08/2014, 13:12
| ||||
| ||||
| Respuesta: sumar con comas La única forma en que los números estén almacenados así es que hayas declarado el campo como VARCHAR, cosa que es un error de los calamitosos. Estas confundiendo el tipo de campo de almacenamiento con la representación de los datos en pantalla.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |
|
19/08/2014, 09:32
| |||
| |||
| Respuesta: sumar con comas los precios o los datos que tengan que ver con dinero deben guardarse como DOUBLE el cual solo te guardará puntos decimanes para poder consultarlos en php en formato de numero es otra cosa. |
|
19/08/2014, 09:40
| ||||
| ||||
| Respuesta: sumar con comas Entonces deberás procesarlo programáticamente, y de ser posible obligar a quien te provee los datos a que respete ciertas normas, como por ejemplo los formatos numéricos y los de fecha. La información que tienes la estás recibiendo "sucia", y de datos sucios sólo se obtiene basura. O la normalizan ellos o la normalizas tu, pero si no se puede, la consulta es imposible en una query. REqueriría usar tablas temporales y procesamiento masivo de datos para corregir el error. Por otro lado, una aclaración: DOUBLE no es un tipo de dato nativo de MySQL para valores monetarios, En MySQL (Ver manual de referencia ante cualquier duda), se especifica que el tipo de dato adecuado y recomendado es DECIMAL. Cita: 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. Cuando se declara una columna de alguno de estos tipos, la precisión y la escala puede especificarse (y usualmente se hace), por ejemplo:
Código MySQL:
Ver original En este ejemplo, 5 es la precisión y 2 es la escala. La precisión representa el número de dígitos decimales significativos que se almacenan para los valores, y la escala representa el número de dígitos que pueden almacenarse a continuación del punto decimal. Desde MySQL 5.0.3, los valores DECIMAL y NUMERIC se almacenan en formato binario. Antes de 5.0.3, MySQL almacena los valores DECIMAL y NUMERIC como cadenas de caracteres, en lugar de binario. .Un carácter se usa para cada dígito del valor, el punto decimal (si la escala es mayor que 0), y el signo '-' (para números negativos). Si la escala es 0, los valores DECIMAL y NUMERIC no contienen punto decimal o parte fraccional. SQL estándar requiere que la columna salary sea capaz de almacenar cualquier valor con cinco dígitos y dos decimales. En este caso, por lo tanto, el rango de valores que puede almacenarse en la columna salary es desde -999.99 a 999.99. MySQL fuerza este límite desde MySQL 5.0.3. Antes de 5.0.3, MySQL 5.0 variaba este límite de forma que, en el límite positivo del rango, la columna podía almacenar números hasta 9999.99. (Para números positivos, MySQL 5.0.2 y anteriores usaba el byte reservado para el signo para extender el límite superior del rango.) En SQL estándar, la sintaxis DECIMAL(M) es equivalente a DECIMAL(M,0). Similarmente, la sintaxis DECIMAL es equivalente a DECIMAL(M,0), donde la implementación se permite para decidir el valor de M. Ambas formas de los tipos DECIMAL y NUMERIC se soportan en MySQL 5.0. El valor por defecto de M es 10. El máximo rango de los valores DECIMAL y NUMERIC es el mismo para DOUBLE, pero el rango real para un valor dado en una columna DECIMAL o NUMERIC puede restringirse con la precisión o escala para una columna dada. Cuando en tal columna se asigna un valor con más dígitos siguiendo el punto decimal de los permitidos por la escala específica, el valor se convierte a tal escala. (El comportamiento preciso depende del sistema operativo, pero generalmente el efecto es que se trunca al número de dígitos permitidos.) Cita: El hecho de que MySQL implemente el DOUBLE como FLOAT, implica que se transforma en un número de aproximación y no precisión.En SQL estándar, los tipos REAL y DOUBLE PRECISION no aceptan especificaciones de precisión. MySQL soporta una sintaxis alternativa con dos números dados entre paréntesis a continuación del nombre del tipo. El primer número representa el ancho a mostrar y el segundo número especifica el número de dígitos a almacenar y mostrar a continuación del punto decimal. Como una extensión al estándar SQL, MySQL reconoce DOUBLE como sinónimo del tipo DOUBLE PRECISION . En contraste con el requerimiento estándar que la precisión para REAL sea menor que la usada para DOUBLE PRECISION, MySQL implementa ambas como valores de punto flotante de doble precisión con tamaño de ocho bytes (a no ser que el modo SQL del servidor incluya la opción REAL_AS_FLOAT ). Hay que tener cuidado con eso.
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |
| Etiquetas: |
