Blog de marketing digital y SEO

La importancia de escoger correctamente el tipo de campo numérico

gravatar
Por David Garcia
Post publicado en Programación
COMPARTIR

Recientemente hemos tenido la oportunidad de participar en la resolución de una incidencia que nos ha traído de cabeza durante la jornada. De aquellos casos que a priori parecen sencillos pero que una vez se empiezan a revisar a fondo provocan más de una risa nerviosa y deseos de volver a fumar.

La incidencia concreta nos la envió un cliente que utiliza para su facturación un desarrollo propio en php + mysql.

Habitualmente no se reportaban problemas con el sistema. Se podían dar de alta nuevas facturas, nacionales, internacionales, intracomunitarias, etc. Incorporando diferentes conceptos con varios tipos de ivas, recargos, irpfs, etc y todo funcionaba perfectamente.

Pero de tanto en tanto el cliente detectaba descuadres de unos pocos céntimos en algunas de las facturas.

En un principio lo resolvía directamente modificando los importes a mano, pero con el transcurso del tiempo, los descuadres fueron aumentando. No en importe, pero sí en el total de facturas.

Un punto común en las facturas era que todas las que presentaban descuadres eran a partir de 10.000€

Empezamos mirando el proceso de alta por parte del usuario para descartar posibles errores humanos. Viendo que todo era correcto y confirmando que el problema aparecía siempre con facturas de ese importe mínimo nos permitieron acceder al código para revisar.

Una vez realizada la comprobación del código fuente el diagnóstico reveló que no había nada fuera de lo común. Los cálculos se realizaban de forma correcta y al realizar operaciones de depuración los importes eran los correctos.

Lo que sí detectamos era que el momento en el que los valores se volvían incorrectos era al guardarlos y recuperarlos de la base de datos.

Volvimos nuestra atención a la base de datos y empezamos a revisar las tablas involucradas. Efectivamente los importes aparecían incorrectos.

Hicimos un duplicado de la base de datos y empezamos a trastear con la misma. Al momento observamos que si intentábamos modificar los valores incorrectos para poner bien los decimales, al volver a cargar la tabla, parecía como si no hubiéramos hecho cambio alguno.

Lo mismo sucedia dando de alta datos nuevos. Por ejemplo al intentar ingresar el valor 10000,37€ en la base de datos se guardaba 10000.4€ En este caso el redondeo se realizaba hacia arriba.

Vimos que el campo “importe” se había definido de tipo “FLOAT”. De entrada ya nos parecio muy extraño, debido a que este campo, tal y como aparece en la documentación de MySQL (http://dev.mysql.com/doc/refman/5.7/en/floating-point-types.html) un campo FLOAT representa valores aproximados.

Es un tipo de datos pensado para cálculos científicos, cálculos de renderizado de modelos 3D o bien distancias entre planetas por poner algunos ejemplos en los que la precisión absoluta no es importante.

Es un campo que opera a nivel binario, con lo que la velocidad que proporciona al realizar operaciones con campos del mismo tipo no tiene rival.

Igualmente esto es lo que provoca que no sea apto para guardar datos con decimales. Simplificando, el problema es que es muy difícil representar exactamente datos decimales utilizando valores binarios (0,1).

Por ejemplo, para el valor 1,1 en decimal, si lo guardamos quedaría: 1.0001100110011001100110

Es un valor periódico, con lo que este mismo valor, al transformarlo de nuevo en decimal ya no nos daría 1,1 si no: 1.09999990463256835937

Esto por ejemplo, con el valor 1,75 por ejemplo, no sucede, ya que en binario se representa como: 1.110

Que al volver a representarse como decimal nos deja con el mismo 1,75

Una explicación mucha más extensa de lo anterior está desarrollada en este documento (http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html)

Cuando de lo que se trata es de guardar importes financieros lo recomendable es utilizar el tipo de campo DECIMAL.

Este tipo de campo si bien no es tan rápido para realizar operaciones como su contrapartida FLOAT sí que nos asegura que el valor que introducimos se guarda exactamente como queremos evitando inconsistencias de datos.

Sobretodo en facturas en las que sí hay errores de céntimos de euro en muchos de los conceptos de una factura al final, por acumulación, podemos llegar a tener desviaciones importantes. Por ello el mayor problema se presentaba en facturas a partir de 10000€ debido a que estas contenían un gran número de conceptos con pequeños descuadres.

Con solo convertir todos los campos afectados, pasando de FLOAT a DECIMAL, el cliente ya no ha vuelto a observar nuevos errores procedentes de descuadres.

newsletter 0 comentarios

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

Mejora tu posicionamiento web

Empieza hoy
BCN
Calle Sancho de Ávila 52, 4º 2º
08018, Barcelona - Tel. 933 686 411
MAD
Calle Ribera de Loira 46, Edificio 2 Bajos
28042, Madrid - Tel. 910 052 175