Cita: No me aclaro, suponiendo que la tabla se llame AA y la columna BB como seria exactamente la sentencia?
Exactamente igual, cambiando el nombre de la tabla de ejemplo por el de la tuya, y el nombre del campo de ejemplo, por el que necesites.
Cita: No entiendo porque se le suma 0.9 no habria que restarselo?
Usa el razonamiento: Es evidente que se trata de un error de tipeo:
Esta multiplicación es equivalente a
pero se escribe mas simple.
¿Conoces el concepto de "tasa"? Bueno, eso es lo que estoy aplicando.
Cita: Condicion no debe cumplir ninguna, ya que quiero modificar todos los registros existentes.
Pues no le pongas el WHERE... yo te estoy mostrando un
ejemplo, algo genérico. No te estoy diciendo que las condiciones sean obligatorias.
Cita: Tambien deberia de redondear para que los numeros no se quedasen fraccionados, porque si uno de los registros fuera 55 el resultado de la modificacion seria 49,5
Esta es la única nota interesante de tu respuesta, aunque denota algún tipo de falta de práctica en SQL.
En SQL una asignación de valor de acuerdo a una operación de división o con numeros decimales, se almacenará
respetando el tipo de dato que tenga definida la columna, y no necesariamente el resultado exacto de la operación.
Si la columna es INT, tu puedes querer asignarle esto:
pero al ser un INT, sólo se almacenará un cero (0).
¿Por qué?
Bueno, simplemente porque
un INT no puede almacenar decimales. Así de simple.
Para almacenar decimales se deben usar campos de tipo DECIMAL o FLOAT, no INT ni en ninguna de sus variantes (TINYINT, SMALLINT, MEDIUMINT, INT BIGINT).
MySQL, cuando intentas almacenar un decimal en un entero, redondeará el valor hacia abajo o hacia arriba dependiendo de qué decimales existan luego del punto. entre el 1 y 4 decimales, trunca; entre el 5 y el 9, redondea hacia arriba.
Ahora bien, el uso de FLOAT sólo tiene sentido en cálculos científicos, y no se recomienda para valores de precisión (valores monetarios, por ejemplo), ya que los FLOAT son
numeros decimales por aproximación, con lo que el 1 como entero no existe, sino el 0.999999999999999999998, por dar un ejemplo.
¿Se entiende?
Esto último no es algo privativo de MySQL. Es un problema que existe en los sistemas de representación numéricos que se usan en los sistemas digitales. Todos. Sólo que los sistemas de las computadoras tienen algoritmos específicos y métodos de conversión para hacer entendible en lenguaje humano los numeros que se manejan.
No te olvides que las computadoras trabajan en binario, y en binario no existen los decimales.Luego, hay métodos para almacenar decimales... en binario.
El problema es que algunas veces el error se filtra a los datos que manejas en tus programas, y hay que saber como resolver el incidente.