| |||
tipo de dato hola!.. espero que puedan ayudarme.. es algo sencillo.. pero estoy en mis primeros pasos.. que tipo de dato debe ser un campo que va a contener una catidad monetaria?..osea que lleva punto decimal?..segun yo debe ser decimal.. o float.. o algo asi no?pero en la aplicacion me arroja el siguiente error..You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''123123123123.09')' at line 1 |
| ||||
Respuesta: tipo de dato Debe ser decimal. Eso error te arroja al insertar o al crear la tabla?
__________________ "El conocimiento nos hace responsables." twitter: @benjamingb blog personal: http://codigolinea.com ZF Manual en español http://manual.zfdes.com |
| ||||
Respuesta: tipo de dato como haces la inserción? puedes poner el query?
__________________ "El conocimiento nos hace responsables." twitter: @benjamingb blog personal: http://codigolinea.com ZF Manual en español http://manual.zfdes.com |
| |||
Respuesta: tipo de dato Código PHP:
Código:
el campo es el de monto |
| ||||
Respuesta: tipo de dato Lo que te confiene es definirlo como FLOAT o DOUBLE, ya que cuando manejas valores monetarios el problema no está en los decimales sino en los redondeos que se hace y que en su acumulación pueden representar cifras siderales. Me explico: Si quisieras recortar el quinto decimal y transferirlo a otra variable, en un balance de cuentas de ventas, podría parecer una nimiedad (es un diezmilésimo), pero imagínate el efecto en el balance de una empresa que realiza 120.000 transacciones diarias (no hablemos las que hace eso en un minuto): El resultado sería la acumulación de 12 unidades monetarias por cada día... es decir, alquien se está quedando con 360 unidades monetarias en un mes, y que pertenecen a la empresa. No es una exageración, desde hace años las empresas saben que ese tipo de fraudes son posibles, cuando los sistemas no calculan bien las fracciones por detrás del máximo de decimales representables. Es una historia que viene desde la época de los maiframes de los años 50 y 60... En definitiva esto se soluciona de una forma simple: 1. Los almacenamientos se hacen como DOUBLES o FLOAT por su mayor precisión (técnicamente hablando el tipo CURRENCY en algunos DBMS es un REAL, DOUBLE o FLOAT de la máxima precisión del sistema). 2. Las representaciones de los datos para las consultas se hacen con DECIMAL(X,2), siendo X la cantidad de decimales enteros a representar en el sistema. Toda otra solución es sospechosa en una auditoría... No te olvides nunca que lo que debes representar es lo que el usuario debe ver, pero eso no quiere decir que eso es lo que se deba almacenar (un ejemplo sería que las SUMAS de una factura no se almacenan, se almacenan los valores que se sumarán; los valores calculables generan almacenamiento inútil y ocupan espacio).
__________________ ¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente... "El problema es la interfase silla-teclado." (Gillermo Luque) |