Consulta. Suma vs tabla totales.

[xerifandtomas]

Actualmente se dispone de una tabla que registra las entradas y salidas del stock.

Reg_stock
Id_reg_stock
Id_almacen
Id_material
Cantidad
Fecha

De momento no presenta problemas en cuanto a velodidad, las dos consultas más utilizadas sobre la tabla son dado un almacén obtener el total de materiales sumando sus cantidades y dado un material obtener el total en sus respectivos almacenes.

En ambas consultas se utiliza la función SUM () y la cláusula GROUP BY.

Esta tabla, crece rápidamente y me preocupa que en un futuro tenga problemas, ya que en la mayoría de consultas necesita ser recorrida por completo.

La idea está en crear otra tabla que almacene solo los totales de cada material para cada almacén, pasando de tener una tabla que crece de forma ilimitada y que en ciertas consultas podrían dar problemas a futuro (creo), a tener una tabla bastante reducida que sólo crecería en
"n° materiales x n° almacenes" y seria actualizada por cada registro que se haga en la tabla Reg_stock.

La pregunta.
De no hacer esto tendré problemas?
Es algo innecesario, por lo que no debería de preocuparme?
El coste para mysql de sumar un gran número de registros (1/5M aprox. De momento) es alto y poco recomendable?

[gnzsoloyo]

Es algo parecido a una "tabla de hechos", es un caso que en realidad debería aplicar a un datawarehouse, y no a consultas sobre la base productiva.
Te conviene crear una tabla para registrar los datos consolidados de entradas y salidas, de modo de no tener que realizar consultas históricas a la base productiva. de ese modo puedes tomar la fecha máxima de esa tabla como parámetro inferior de una consulta a la productiva, ya que los restantes datos anteriores ya estarán resumidos en esta otra tabla.

¿Se entiende la idea?
Lo que NO debes hacer es agregar una columna de sumatorias a la tabla de productos. Sólo servirá para complicar las cosas.

[xerifandtomas]

Gracias gnzsoloyo por la respuesta. He leido el enlace que me has dado y varios de los enlaces interno.

Creo haberte entendido, pero tu última frase me deja un poco confuso.

Iniciado por gnzsoloyo

Lo que NO debes hacer es agregar una columna de sumatorias a la tabla de productos. Sólo servirá para complicar las cosas.

¿No debo crear un campo total en la nueva tabla o en la tabla actual de productos?

En la base de datos actual sobre la tabla Productos (materiales en este caso) no almaceno ni tengo ningun campo con el total o con la sumatoria de un producto dado, ni pretendo crearlo ya que no me valdria para nada al tener varios almacenes (mas que para duplicar registros), si no que actulamente se calcula a parti del campo cantidad (smallint) de la tabla Reg_stock, dicha tabla almacena los movimientos del stock siendo el campo catidad un numero positivo para las entradas y un numero negarivo para las salidas.

Lo que entiendo es que se debe crear una nueva tabla que almacene los totales de cada producto en cada uno de los almacenes.


Pudiendo quedar una tabla algo asi, a modo de ejemplo:

Totales_productos_almacenes
id_Totales_productos_almacenes
id_producto
id_almacen
total
fecha_ultimo_cambio

Y actualizar el registro pertiente de dicha tabla cada vez que haya un movimiento en el stock.
Eliminando la necesidad de calcular la suma de cantidades del registro de entradas y salidas en base a todo el historico de registros.


¿Es esto correcto o te he mal interpretado?

[gnzsoloyo]

¿No debo crear un campo total en la nueva tabla o en la tabla actual de productos?

Exacto. Eso se denomina "campo calculable" y son un error de diseño.

Lo que entiendo es que se debe crear una nueva tabla que almacene los totales de cada producto en cada uno de los almacenes.

Esa es mas o menos la idea, pero no los totales generales, sino los totales por periodo. Los generales se siguen calculando pero sobre valores preconsolidados.

Pudiendo quedar una tabla algo asi, a modo de ejemplo:

Totales_productos_almacenes
id_Totales_productos_almacenes
id_producto
id_almacen
total
fecha_ultimo_cambio

Y actualizar el registro pertiente de dicha tabla cada vez que haya un movimiento en el stock.

NO, no y no. Eso seguiría exigiendo operaciones periódicas para actualizar el datos, lo que sigue siendo malo.
A lo que yo me refiero es a registrar los totales por periodo, sean estos mensuales, quincenales, semanales diarios y hasta por hora si quieres. El nivel de agregación sería algo que tienes que definir tú. En cuanto a la fecha ultima, simplemente tomas el ultimo periodo consolidado y realizas la consulta sobre el restante tiempo, lo que te acotará mucho la consulta.

[xerifandtomas]

Buenas gnzsoloyo y gracias por tus respuestas.

He estado leyendo al respecto de la consulta y creo que ahora si que entiendo lo que me explicabas en cuanto en cuanto a crear una tabla con los datos consolidados estableciendo el grosor del grano tan fino (días, horas,...) o tan grueso (meses, años,...) como sea oportuno.

Básicamente y perdoname si me equivoco, esta nueva tabla que será casi una copia de la actual almacenará el estado de los almacenes y sus artículos para un momento o período dado, agregando el estado actual del almacén y sus materiales cada vez que finalice un periodo, que a su vez vendrá dado por el grosor del grano elegido.
Por lo que contendrá un registro por cada almacén y material existente en ese periodo.

Para recuperar el estado supongamos, de un artículo y en un determinado almacén en el momento actual, se debe hacer una consulta que implique ambas tablas. Extrayendo de la nueva tabla el registro del último periodo( el más reciente ) y de la tabla general todos aquellos registros más recientes al último periodo guardado para ese artículo y almacen dado. Realizando la sumatoria sobre este grupo de registros.

Es esto correcto?