|
Control de stock por almacenes.
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. |
Cita:
La consiguiente relación m..n entre las tablas artículo/almacen y la tabla resultante que es la que tú comentas. |
Correcto...
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 |
pos eso.
Pos era por tener una segunda opinión. Gracias de todas formas.
|
Te doy otra opción....
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 |
Cita:
No usar tablas, hay que usar querys con los registros que se han pedido. |
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 |
Es cierto
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 |
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:
Código:
numero_material | material | numero_almacenCódigo:
numero_material | numero_almacen |
Cita:
// Saludos |
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.:D Pero estoy convencido que tu criterio es mejor. Saludos |
Cita:
|
Ves hasta ArdiIIa me da la razon:D
Si en su nevera no entran.:rolleyes: Saludos |
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? :D
// Saludos |
Cita:
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". |
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 |
Hola
Despues de esto: Cita:
Y mas si son vinos del Penedes especialmente un sangre de Toro.:D Saludos |
Cita:
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 |
Y va otra
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.... |
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?:confused: :D Saludos |
| La franja horaria es GMT +2. Ahora son las 23:57:58. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi