Control de stock por almacenes.

[Producto77]

Hola al grupo:
Quiero poner en una aplicación el control de stock de materiales por almacenes. Tengo que dejar al usuario poder crear todos los almacenes que quiera.
Se me ocurre crear una tabla llamada almacen-stock, donde guardo el CodAlmacen, CodArticulo, Existencias. Pero danto vueltas y pensando,,,, cuando tenga 9.000 artícullso y 3 almacenes,,,,,, 27.000 registros.
Alguien puede darme alguna ayudilla, u otra idea mejor.

Gracias por adelantado.

[Neftali [Germán.Estévez]]

Empezado por Producto77

...donde guardo el CodAlmacen, CodArticulo, Existencias. Pero danto vueltas y pensando,,,, cuando tenga 9.000 artícullso y 3 almacenes,,,,,, 27.000 registros.

Creo que esa esla mejor.
La consiguiente relación m..n entre las tablas artículo/almacen y la tabla resultante que es la que tú comentas.

[waly2k1]

Es la manera correcta de administrar el stock, no te preocupes por la cantidad de registros que un motor de base de datos real lo soporta tranquilamente, además no traerías los 27000 registros por cada acceso a las tablas sino el/los articulos en cuestión y los registros relacionados de la tabla de stock. Eso sí, prestá mucha atención a los índices y claves primarias de cada tabla.

Saludos

[Producto77]

Pos era por tener una segunda opinión. Gracias de todas formas.

[waly2k1]

Abres la tabla de artículos con un TTable y cuando te 'mueves' de registro, mediante un TQuery abres los detalles de stock, de ésta forma vas a tener unicamente los 3..N (almacenes) en detalles. Pero esto implica un acceso a la tabla cada vez que cambias de registro en el maestro lo cual es un flash igualmente si posee clave primaria o índice por articulo/almacen.

Salu2

[Casimiro Notevi]

Empezado por waly2k1

Abres la tabla de artículos con un TTable y cuando te 'mueves' de registro, mediante un TQuery abres los detalles de stock, de ésta forma vas a tener unicamente los 3..N (almacenes) en detalles. Pero esto implica un acceso a la tabla cada vez que cambias de registro en el maestro lo cual es un flash igualmente si posee clave primaria o índice por articulo/almacen. Salu2

Precisamente, eso es justo lo que no hay que hacer.
No usar tablas, hay que usar querys con los registros que se han pedido.

[[Caral]]

Hola
Yo Haria dos tablas, una almacen, donde se encuentren todos los almacenes y otra materiales donde se encuentren todos los materiales.
Si quiero ligar los materiales con el almacen a la tabla materiales le pongo un campo NumerodeAlmacen.
Asi tengo la cantidad de almacenes que quiera ligada a una sola tabla Materiales, el control es mucho mas facil.
Por cierto lleva razon Casimiro Notevi, hay que hacer lo posible por usar querys, ya que estos solo envian la informacion que se les pide, por el contrario los tables mandan toda la informacion y alenta el programa.
Saludos

[waly2k1]

Es cierto lo que dicen muchachos, pero de cuántos registros estamos hablando 10.000 ? y del lado del cliente ?. No es nada, si me dicen millones obviamente no utilizaría una tabla completa y cargar una grilla. Igualmente les doy la razón.

Saludos

[roman]

Hola Caral. El problema con lo que planteas es que para tener el mismo material en más de un almacén, tendrías que duplicar la entrada:

numero_material | material                | numero_almacen
...

87              | camisas de manga corta  |     2
...
87              | camisas de manga corta  |     5
...

En cambio, si dejas la tabla de materiales sólo con la información específica de materiales, puedes usar una tercera tabla, almacen-material, que es la que lleva el registro de qué materiales hay en qúe almacenes y qué cantidad

numero_material | numero_almacen
...

87              | 2
...
87              | 5
...

// Saludos

[roman]

Empezado por waly2k1

Es cierto lo que dicen muchachos, pero de cuántos registros estamos hablando 10.000 ? y del lado del cliente ?.

¿Cómo de que no es mucho? Yo opino que sí lo es. Más de doscientos registros puede ser mucho. Diez mil es demasiado y puede afectar notablemente el rendimiento.

// Saludos

[[Caral]]

Hola Roman
Cierto, pero tal vez como novato veo un poco mas complicado ligar mas de dos tablas, teniendo en cuenta que por ejemplo en mi empresa tengo no mas de 300 materiales y que en un almacen de licores no tendras mas de 1000 productos.
No veo mucha cantidad de registros incluso teniendo 30 almacenes.
Pero si veo por ejemplo que se pueda organizar la tabla por almacen y se podrian ver y buscar los productos o materiales con suma facilidad.
No se es cuestion de conocimiento, a mi me cuesta ligar muchas tablas.
Pero estoy convencido que tu criterio es mejor.
Saludos

[[ArdiIIa]]

Empezado por Caral

Hola Roman
en un almacen de licores no tendras mas de 1000 productos.
Saludos

!! Yo en mi nevera, tengo dos o tres menos Hipp Hipp

[[Caral]]

Ves hasta ArdiIIa me da la razon
Si en su nevera no entran.
Saludos

[roman]

Pero eso es por falta de capacidad de la 'base de datos'. De otra forma, ¿quién se negaría a hacer los enlaces que se requiriesen para agrandar la cava?

// Saludos

[Neftali [Germán.Estévez]]

Empezado por Caral

...dos tablas, una almacen, donde se encuentren todos los almacenes y otra materiales donde se encuentren todos los materiales.
Si quiero ligar los materiales con el almacen a la tabla materiales le pongo un campo NumerodeAlmacen.

El problema de esto, es que aunque a primera vista parece más sencillo, a la larga te da más problemas de mantenimiento, de integridad e incluso puede resultar menos eficiente.

Por ejemplo:
* Si tienes que cambiar la descripción de un artículo (porque se ha modificado), debes cambiarla en varios registros, ya que segun el caso la tendrás repetida en varios de ellos (segun los almacenes).
* También puede pasar que al tenerla repetida, tengas inconguencas en el mismo artículo:
...
87 | Camisas de manga corta | 2
87 | camisa de manga corta | 5
...
* El tenerlo de esta forma, también te limita a la hora de utilizar reglas en CASCADA de la Base de Datos.

Ya se que en este caso, son cosas mínimas porque hablamos de una estructura muy pequeña, pero luego los problemas van creciendo sin darse uno cuenta y ejor empezar "bien".

[[Lepe]]

Hasta ahora no se ha hablado de la Base de Datos, si usamos paradox....ummm, pero usando un SGBBDD, podemos usar vistas que ya ligan (por inner join) las tablas necesarias, haciendo más fácil su uso desde consultas.

Saludos

[[Caral]]

Hola
Despues de esto:

¿quién se negaría a hacer los enlaces que se requiriesen para agrandar la cava?

La verdad tienes razon.
Y mas si son vinos del Penedes especialmente un sangre de Toro.
Saludos

[roman]

Empezado por Lepe

Hasta ahora no se ha hablado de la Base de Datos, si usamos paradox....ummm, pero usando un SGBBDD, podemos usar vistas que ya ligan (por inner join) las tablas necesarias, haciendo más fácil su uso desde consultas.

No estoy muy puesto con el tema, pero aunque no te quito la razón, supongo que las vistas facilitarán la labor de quien haga las consultas suponiendo que es una persona distinta de quien hace la vista. Esto es, las relaciones de cualquier manera se tienen que hacer, sea del lado del servidor o sea del lado del cliente.

De cualquier manera, y luego de una copita, creo que estamos de acuerdo en que lo óptimo es estructurar las tablas con la tabla asociativa material-almacen por las razones expuestas por Neftalí.

// Saludos

[waly2k1]

No veo porque tanta complicación,
Tengo dos tablas: Una Articulos y otra STock

Articulos
Id_Articulo
Descripcion
Id_Familia
Precio_Costo
etc.

Stock
Id_Articulo
Id_Almacen
Cantidad

No tengo campos repetitivos, solo el codigo del articulo.
mediante left join uno una tabla con la otra, ojo Left por si ese articulo no está en stock no lo muestra.

Y si quiero hilar mas fino mediante una consulta voy uniendo campos a Articulos de modo que cada Cantidad de la tabla Stock me resultaría un campo de la tabla articulo en la consulta.

Y es to to todo amigos....

[[Caral]]

Hola
Si waly2k1, pero tu tabla Stock, es en esencia la tabla material-almacen que propone Roman, siempre se necesitara la tabla Almacen adicionalmente.
Me equivoco Roman?
Saludos