Duplicar informacion o recalcular datos??

Tengo un cliente, que realiza por lo menos 70,000 ventas mensualmente en una
de sus sucursales, en las 4 restantes el promedio mensual es de 30 a 40 mil
ventas, si a eso sumamos las compras mas todos los ajustes de inventarios
que pueden estar incluidos y tomando en cuenta que todo esto esta almacenado
en un solo servidor, te podria decir que a la altura de 6 años de historia
pensar en recalcular datos, seria de por si, sin sentido, yo te recomiendo
que vayas llevando una tabla con acumulados mensuales, otra con acumulados
diarios por que de esa forma se te hara mas sencillo poder presentar hasta a
nivel de un Kardex la informacion en mi caso tengo dos tablas asi:


IdProducto Int,
MesAnio char(7)
Inicial Int, ** Inicial tiene como default una funcion que calcula el valor
final del registro correspondiente anterior
Ingresos int,
Salidas int,
Final Int ** es una simple funcion que hace (Inicial+Ingresos)-Salidas

esta tabla almacena a nivel de mes y año, dado que la base de datos se
compone de 52,345 articulos es muy eficiente

luego tengo la misma estructura pero por dia y nomas tengo que calcular a la
hora de solicitar un informe de donde extraer el saldo inicial. simple pero
efectivo.



"Ace" escribió en el mensaje de noticias
news:

Hola a todos! Tengo una duda a nivel de diseño que supongo que más de uno
se ha encontrado.

Me dispongo a crear una base de datos que va a controlar un almacén de
productos.

A la hora de tratar este almacén no se si es mejor guardar en un registro
la cantidad de producto que tenemos en el almacén o calcularlo restando
las salidas a las entradas de los mismos.

La teoria dice que, usando una base de datos relacional, deberíamos
recalcular la información antes de duplicarla. Pero suponiendo que el
almacén va a generar un gran número de entradas y salidas diarias y que el
programa puede estar funcionando durante muchos años ¿puede que el proceso
de calcular el stock actual se haga muy costoso?¿quizá es mejor guardar el
stock actual en un registro?¿Tal vez lo mejor es una solución intermedia
como guardar los stock anuales una vez cerrado el ejercicio?..
Saludos!!! y gracias.

Hola Ace,

A veces la teoría esta incompleta, por ejemplo cuando dicen:

"deberíamos recalcular la información antes de duplicarla"

Deberían completar la frase quedando mas o menos de esta forma:

"deberíamos recalcular la información antes de duplicarla siempre y cuando
el recalculo no nos consuma el 100% de los recursos y el tiempo para
obtenerla sea el deseado o esperado por el cliente"

Yo me encontré con el mismo problema que vos, tenia una versión de un
sistema en donde guardaba el stock actual, cuando desarrolle una nueva
versión me fui a la teoría y la tabla de stock actual la hice desaparecer,
!! total para calcularlo hago la sumatoria de los movimientos !!, esto
funciono hasta que para algunos clientes que tenían unos 50.000 movimientos
por articulo el "recalculo" se hacia insoportable, corte por lo sano y volví
al viejo método, le agregue nuevamente la tabla de stock actual y
solucionado el problema.

Entonces tengo una tabla de movimientos al stock y otra tabla con los saldos
actuales de tal manera que la sumatoria de los movimientos coincide con la
tabla de saldos, si en algún momento se desincronizan, cosa rara porque las
actualizaciones están anidadas en una transacción, puedo reconstruir la
tabla de saldos partiendo de la de movimientos.

Cuando depuro movimientos al stock el proceso genera un único movimiento con
el resultado de las cantidades para los movimientos depurados de tal forma
que aun conservo la relación antes descripta, es decir, la sumatoria de los
movimientos coincide con la tabla de saldos de stock.

Para recalcular un saldo de stock a una fecha no queda mas remedio que
recalcular, en este caso parto del saldo actual, resto las entradas y sumo
las salidas de los movimientos "posteriores" a la fecha a la cual quiero
obtener el saldo historico.

Un saludo, Víctor Koch.


"Ace" escribió en el mensaje
news:

Hola a todos! Tengo una duda a nivel de diseño que supongo que más de uno

se

ha encontrado.

Me dispongo a crear una base de datos que va a controlar un almacén de
productos.

A la hora de tratar este almacén no se si es mejor guardar en un registro

la

cantidad de producto que tenemos en el almacén o calcularlo restando las
salidas a las entradas de los mismos.

La teoria dice que, usando una base de datos relacional, deberíamos
recalcular la información antes de duplicarla. Pero suponiendo que el
almacén va a generar un gran número de entradas y salidas diarias y que el
programa puede estar funcionando durante muchos años ¿puede que el proceso
de calcular el stock actual se haga muy costoso?¿quizá es mejor guardar el
stock actual en un registro?¿Tal vez lo mejor es una solución intermedia
como guardar los stock anuales una vez cerrado el ejercicio?..
Saludos!!! y gracias.

On Tue, 13 Mar 2007 20:56:51 +0100, "Ace" wrote:

La teoria dice que, usando una base de datos relacional, deberíamos
recalcular la información antes de duplicarla.

Correcto.

Pero suponiendo que el
almacén va a generar un gran número de entradas y salidas diarias y que el
programa puede estar funcionando durante muchos años ¿puede que el proceso
de calcular el stock actual se haga muy costoso?¿quizá es mejor guardar el
stock actual en un registro?

Mejor que SQL Server se encargue de eso. Mira como funcionan las
vistas indexadas.

A mi me funciona de maravilla.

Otra solución es comenzar con una vista normal y si ves que en algún
momento empieza ir lento, entonces la indizas y listo. Las
aplicaciones no habría que tocarlas para nada.


Saludos

On Wed, 14 Mar 2007 11:34:17 -0300, "Victor Koch" <v i c t o r
(arroba)correo(punto)waldbott(punto)com(punto)ar> wrote:

Hola Ace,

A veces la teoría esta incompleta, por ejemplo cuando dicen:

"deberíamos recalcular la información antes de duplicarla"

Deberían completar la frase quedando mas o menos de esta forma:

"deberíamos recalcular la información antes de duplicarla siempre y cuando
el recalculo no nos consuma el 100% de los recursos y el tiempo para
obtenerla sea el deseado o esperado por el cliente"

Y también debería decir que si el tiempo para obtenerla no puede ser
el deseado habría que cambiar de SGBD (por ejemplo de MySQL a SQL
Server).

Yo me encontré con el mismo problema que vos, tenia una versión de un
sistema en donde guardaba el stock actual, cuando desarrolle una nueva
versión me fui a la teoría y la tabla de stock actual la hice desaparecer,
!! total para calcularlo hago la sumatoria de los movimientos !!, esto
funciono hasta que para algunos clientes que tenían unos 50.000 movimientos
por articulo el "recalculo" se hacia insoportable, corte por lo sano y volví
al viejo método, le agregue nuevamente la tabla de stock actual y
solucionado el problema.

Te hubiese sido mucho más sencillo "indizar" una vista.


Saludos