Cita:
Iniciado por gnzsoloyo 
Lo que tienes no es un problema de consulta, sino una inconsistencia de datos...
Según lo que posteaste, lo que tienes en esa tabla es esto:
Código MySQL:
Ver original
mysql> use stocklentesbrujuleando3
Database changed
mysql> SELECT
-> id_item,
-> IFNULL(compra, 0) compra,
-> IFNULL(taller, 0) taller,
-> IFNULL(venta, 0) venta,
-> IFNULL(regula_mas, 0) regula_mas,
-> IFNULL(regula_menos, 0) regula_menos
-> FROM movimiento ;
+---------+--------+--------+-------+------------+--------------+
| id_item | compra | taller | venta | regula_mas | regula_menos |
+---------+--------+--------+-------+------------+--------------+
| 1 | 100 | 0 | 0 | 0 | 0 |
| 1 | 0 | 2 | 0 | 0 | 0 |
| 1 | 0 | 0 | 1 | 0 | 0 |
| 352 | 58 | 0 | 0 | 0 | 0 |
| 352 | 0 | 0 | 0 | 0 | 12 |
| 1 | 0 | 0 | 125 | 0 | 0 |
+---------+--------+--------+-------+------------+--------------+
6 rows in set (0.00 sec)
Si te fijas con cuidado, en el último movimiento tienes una venta de 125 unidades, pero sólo 100 en stock (primer registro)
Sencillamente tienes un error de aplicación porque no estás validando que existan unidades en stock antes de realizar la venta...
bueno, en principio esto lo he hecho para hacer pruebas desde phpmyadmin, para ver que pasaba si me encontraba con un artículo en stock negativo, ya se que no tiene mucho sentido, pero ya digo, era en plan pruebas.
1- sea como sea, se puede arreglar para que te de el resultado negativo sin dar error?
2- cómo tendría que hacer para esa validación de stock previa?
Cita: Por otro lado, observando tus tablas, quisiera hacerte una aclaración...
Ese número "(5)" que estás poniendo es un error porque no representa la cantidad de dígitos que se almacenan. Eso se usa para otras cosas, y eventualmente puede causarte problemas.
Este es un tema recurrente, y para el caso aplica lo que dice el manual de referencia:
Cita:
MySQL supports an extension for optionally specifying the display width of integer data types in parentheses following the base keyword for the type. For example, INT(4) specifies an INT with a display width of four digits. This optional display width may be used by applications to display integer values having a width less than the width specified for the column by left-padding them with spaces. (That is, this width is present in the metadata returned with result sets. Whether it is used or not is up to the application.)
The display width does not constrain the range of values that can be stored in the column. Nor does it prevent values wider than the column display width from being displayed correctly. For example, a column specified as SMALLINT(3) has the usual SMALLINT range of -32768 to 32767, and values outside the range permitted by three digits are displayed in full using more than three digits.
Esto que te resalto dice: "El valor mostrado no restringe el rango de valores que pueden ser almacenados en la columna. Tampoco previene que valores mayores de la columna sean mostrados correctamente".
El único uso que tiene ese numero es para que ciertas aplicaciones que sólo tienen un rango dado fijo de salida, puedan recibir la columna "formateada" adecuadamente, pero no representa al dato.
El rango del dato está dado por su tipo de columna. Lo correcto es que un INT UNSIGNED tenga un ancho de salida de 10, cosa que MySQL pone automáticamente si sólo le indicas el tipo de dato, sin ese valor.
Por otro lado, como ciertas funciones de MySQL leen esa definición de ancho para ciertas tareas (generación de vistas, por ejemplo), podría darse que valores mayores sean leídos incorrectamente, dando resultados erróneos en las consultas, porque MySQ "cortaría" el número, descartando parte de su valor.
En síntesis: No los uses. Deja que MySQL ponga el que corresponda.
Sí se usan con los DECIMAL, pero eso es otro caso completamente distinto, y alli sí tiene sentido usarlos.
pues la verdad no lo sabía, si es un error, no me queda otra que reescribir de nuevo todo, porque las fk deben referenciarse a campos iguales, verdad?