Sistema de stock, cual es la manera de diseniarlo ?

Depende de a qué se le dé prioridad: tu diseño está más orientado a
consultas por el stock (número de elementos que quedan por producto), con lo
que esta consulta será más rápida y eficiente; en contra tiene que tienes
que mantener ese campo de alguna forma (procedimiento almacenado, trigger,
campo calculado, etc), con lo que se penaliza la creación de un nuevo
movimiento (será más lento porque tendrá que hacer más de una operación).

Por otro lado, el planteamiento de tu jefe está más orientado a una
mayor rapidez a la hora de crear un nuevo movimiento, pero penalizará la
consulta de la cantidad de material restante al tener que recorrerse la
tabla de STOCK-MOVIMIENTOS (probablemente usará el índice que crees sobre el
IDProducto, pero aún así será evidentemente más lenta).

Eso es algo que dependerá de los requerimientos de la aplicación, los
dos diseños no son malos per sé...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Sandro" escribió en el mensaje
news:

Entre en una discucion, con mi jefe acerca de como diseniar la base de

datos

de stock, el me plantea lo siguiente:
Una tabla para los productos y otra para los movimientos, hasta ahi todo

de

acuerdo, pero a mi se me ocurrio armara de la siguiente manera
STOCK - PRODUCTOS
IDProducto
Descripcion
Cantidad
etc.

STOCK - MOVIMIENTOS
IDProducto
CantidadMovida
etc.

y para consultar la cantidad disponible simplemente consultar la tabla
STOCK-PRODUCTOS por la cantidad y listo.

Pero mi jefe me plantea que no se tiene que guardar la cantidad disponible
sino que cada ves que quiera saber sobre la cantidad consultar la tabla de
movimientos y hacer el reecuento de los movimientos y de ahi sacar la
cantidad disponible.

Como nunca disenie sistemas para stock y demas, no puedo saber si es la
mejor manera.

Algun aporte, algun link donde sacar informacion ?

Gracias de antemanos

Hola,

Yo me inclinaria por consultar movimientos. Más si tienes en cuenta que esto
te permite, por ejemplo, obtener el stock en una fecha determinada.

"Sandro" escribió en el mensaje
news:

Entre en una discucion, con mi jefe acerca de como diseniar la base de

datos

de stock, el me plantea lo siguiente:
Una tabla para los productos y otra para los movimientos, hasta ahi todo

de

acuerdo, pero a mi se me ocurrio armara de la siguiente manera
STOCK - PRODUCTOS
IDProducto
Descripcion
Cantidad
etc.

STOCK - MOVIMIENTOS
IDProducto
CantidadMovida
etc.

y para consultar la cantidad disponible simplemente consultar la tabla
STOCK-PRODUCTOS por la cantidad y listo.

Pero mi jefe me plantea que no se tiene que guardar la cantidad disponible
sino que cada ves que quiera saber sobre la cantidad consultar la tabla de
movimientos y hacer el reecuento de los movimientos y de ahi sacar la
cantidad disponible.

Como nunca disenie sistemas para stock y demas, no puedo saber si es la
mejor manera.

Algun aporte, algun link donde sacar informacion ?

Gracias de antemanos

Hola Sandro, pues bien, ambos tienen razon :-) veamos un poquito:

Si usas un campo resumen como vos indicas tienes la ventaja de performance,
ya que calcular cada vez el stock puede ser muy pesado para el motor,
imaginate que tienes miles de transacciones? Pues bien, la ventaja es
simple, ahora el tema es la desventaja: Si haces esto no podras asegurar
100% que el valor Stock de tu tabla productos sea el correcto, porque digo
esto? simple: si implementas un trigger (cada transaccion nueva actualiza la
cabecera del producto) puedes tener problemas de:
1) El trigger se puede deshabilitar y chau logica
2) Si alguien corre un DTS y no hace en modo fast se puede obviar el uso de
los mismos :(

Bien, lo que plantea tu jefe tiene la ventaja de confiabilidad 100% en la
informacion, pero la enorme desventaja de la performance :( y este ultimo
punto puede ser un factor muy interesante, hacele recordar a tu jefe que hay
requerimientos que no son funcionales en un sistema (tambien llamado
arquitectura)

Bien, que hacemos entonces? te cuento que hago yo y con muy buenos
resultados: Yo opte por una tercer alternativa que es realizar una vista
indexada con el Stock, entonces solucione los 2 problemas de ambos mundos.
Peroformance: Al ser una vista indexada y tener su indice es muy eficiente
de verdad.
Integridad: Al ser una vista consulta directo en la base, sin triggers ni
nada :-)

Te recomiendo que hagan una prueba y vean lo que pueden hacer con estas
vistas indexadas, a mi en este caso en particular me han sido de mucha
utilidad :-)


Salu2
Maxi


"Sandro" escribió en el mensaje
news:

Entre en una discucion, con mi jefe acerca de como diseniar la base de
datos de stock, el me plantea lo siguiente:
Una tabla para los productos y otra para los movimientos, hasta ahi todo
de acuerdo, pero a mi se me ocurrio armara de la siguiente manera
STOCK - PRODUCTOS
IDProducto
Descripcion
Cantidad
etc.

STOCK - MOVIMIENTOS
IDProducto
CantidadMovida
etc.

y para consultar la cantidad disponible simplemente consultar la tabla
STOCK-PRODUCTOS por la cantidad y listo.

Pero mi jefe me plantea que no se tiene que guardar la cantidad disponible
sino que cada ves que quiera saber sobre la cantidad consultar la tabla de
movimientos y hacer el reecuento de los movimientos y de ahi sacar la
cantidad disponible.

Como nunca disenie sistemas para stock y demas, no puedo saber si es la
mejor manera.

Algun aporte, algun link donde sacar informacion ?

Gracias de antemanos

mucha gracias por los aportes, me ayudaron mucho...

"Sandro" escribió en el mensaje
news:

Entre en una discucion, con mi jefe acerca de como diseniar la base de
datos de stock, el me plantea lo siguiente:
Una tabla para los productos y otra para los movimientos, hasta ahi todo
de acuerdo, pero a mi se me ocurrio armara de la siguiente manera
STOCK - PRODUCTOS
IDProducto
Descripcion
Cantidad
etc.

STOCK - MOVIMIENTOS
IDProducto
CantidadMovida
etc.

y para consultar la cantidad disponible simplemente consultar la tabla
STOCK-PRODUCTOS por la cantidad y listo.

Pero mi jefe me plantea que no se tiene que guardar la cantidad disponible
sino que cada ves que quiera saber sobre la cantidad consultar la tabla de
movimientos y hacer el reecuento de los movimientos y de ahi sacar la
cantidad disponible.

Como nunca disenie sistemas para stock y demas, no puedo saber si es la
mejor manera.

Algun aporte, algun link donde sacar informacion ?

Gracias de antemanos

Maxi,

Integridad: Al ser una vista consulta directo en la base

Muy interesante este tema. Reconozco la utilidad del uso de vistas
indexadas, pero te comento que una vista indexada es considerada una tabla
mas ya que el resultado, a la hora de la creacion, es materializado hacia el
dispositivo de almacenamiento usado. Cada vez que en la tabla, actualizes los
campos involucrados en el indice de la vista, sql server tiene que actualizar
tambien el indice / data materializada de la vista. Las vistas indexadas son
mucho mas complejas de mantener que los indices en una tabla y por lo tanto
Microsoft recomienda su uso en casos donde la velocidad de consulta supera
ampliamente la carga que provoca el mantenimiento de la vista indexada. Esto
se ve principalmente en vistas sobre data relativamente estatica, o que
procesa muchas filas y son referenciadas en muchas consultas.

Sin duda que las vistas indexadas pueden ayudar mucho, pero tengan mucho
cuidado cuando las implementan. A todo esto le agrego que se deben cumplir
una serie de requerimientos para poder crearlas.

Una ultima cosita, para crear vistas indexadas se necesita las versiones
Enterprise / Developer de sql server 2000.


Saludos,

AMB


"Maxi" wrote:

Hola Sandro, pues bien, ambos tienen razon :-) veamos un poquito:

Si usas un campo resumen como vos indicas tienes la ventaja de performance,
ya que calcular cada vez el stock puede ser muy pesado para el motor,
imaginate que tienes miles de transacciones? Pues bien, la ventaja es
simple, ahora el tema es la desventaja: Si haces esto no podras asegurar
100% que el valor Stock de tu tabla productos sea el correcto, porque digo
esto? simple: si implementas un trigger (cada transaccion nueva actualiza la
cabecera del producto) puedes tener problemas de:
1) El trigger se puede deshabilitar y chau logica
2) Si alguien corre un DTS y no hace en modo fast se puede obviar el uso de
los mismos :(

Bien, lo que plantea tu jefe tiene la ventaja de confiabilidad 100% en la
informacion, pero la enorme desventaja de la performance :( y este ultimo
punto puede ser un factor muy interesante, hacele recordar a tu jefe que hay
requerimientos que no son funcionales en un sistema (tambien llamado
arquitectura)

Bien, que hacemos entonces? te cuento que hago yo y con muy buenos
resultados: Yo opte por una tercer alternativa que es realizar una vista
indexada con el Stock, entonces solucione los 2 problemas de ambos mundos.
Peroformance: Al ser una vista indexada y tener su indice es muy eficiente
de verdad.
Integridad: Al ser una vista consulta directo en la base, sin triggers ni
nada :-)

Te recomiendo que hagan una prueba y vean lo que pueden hacer con estas
vistas indexadas, a mi en este caso en particular me han sido de mucha
utilidad :-)


Salu2
Maxi


"Sandro" escribió en el mensaje
news:
> Entre en una discucion, con mi jefe acerca de como diseniar la base de
> datos de stock, el me plantea lo siguiente:
> Una tabla para los productos y otra para los movimientos, hasta ahi todo
> de acuerdo, pero a mi se me ocurrio armara de la siguiente manera
> STOCK - PRODUCTOS
> IDProducto
> Descripcion
> Cantidad
> etc.
>
> STOCK - MOVIMIENTOS
> IDProducto
> CantidadMovida
> etc.
>
> y para consultar la cantidad disponible simplemente consultar la tabla
> STOCK-PRODUCTOS por la cantidad y listo.
>
> Pero mi jefe me plantea que no se tiene que guardar la cantidad disponible
> sino que cada ves que quiera saber sobre la cantidad consultar la tabla de
> movimientos y hacer el reecuento de los movimientos y de ahi sacar la
> cantidad disponible.
>
> Como nunca disenie sistemas para stock y demas, no puedo saber si es la
> mejor manera.
>
> Algun aporte, algun link donde sacar informacion ?
>
> Gracias de antemanos
>
>
>
>
>
>
>