Ayuda en Como Usar Trigger para llevar Control de Stocks de Almacenes

22/08/2005 - 19:15 por Developers | Informe spam
Amigos, estoy por iniciar un proyecto de Gestion de Almacenes de una Empresa
pero mi duda es como llevar un mejor control de los stocks de cada almacen.
Tengo Varias Dudas que detallo a continuacion.

1.- Usar Triggers para la Insercion,Eliminacion o Actualizacion de la Tabla
Stock para cada Movimiento de Codigo de Producto x Documento ("Aclaro que no
tengo mucha experiencia en uso Trigger")

2.- Usar la Clasica Suma de Filas(Stk . Inicial +Ingresos-Salidas) de la
Tabla movimiento.(Aclaro que la Empresa tiene movimientos Grande en sus
almacenes)

Adjunto Estructuras de Tabla:

D_MovAlma <-- Tabla de Detalle de Movimeinto de Almacenes
Nro_Documento char (12) <-- Numero de Documento que Genera el Movimiento
Fecha Smalldatetime <-- Fecha de la Transaccion Originada
Area Char(2) <-- Codigo de Almacen a Donde va Ingresado o Retirado el
Producto
Cod_Prod char(10) <-- Codigo de Producto que Origina la Transaccion
Ing_Ite Decimal (13,5) <-- Si Transaccion es Ingreso ocupada este Campo si
no es CERO
Sal_Ite Decimal (13,5) <-- Si Transaccion es Salida ocupada este Campo si
no es CERO
Estado Char(1) <-- Estado del Documento (de Baja, Impreso)

D_StkArea <-- Tabla que contiene los Stocks Iniciales del AÑo x Cada
Almacen y Producto
Area char(2)
Cod_Prod char(10)
Stk_Inicial decimal(13,5)

falta definir si se crea una tabla para acumular los Ingresos y Salidas x
Area y Codigo ó si se usa acumulacion mediante Sum la tabla ya no existiria.

Me gustaria sus opiones al respecto.

Gracias

Developers

Preguntas similare

Leer las respuestas

#6 Developers
22/08/2005 - 20:49 | Informe spam
Maxi, me gusto la idea de las Vistas Indexadas y tambien me entero recien
que se pueden aplicar a cuaquier version de SQLServer



"Maxi" escribió en el mensaje
news:uP$
Mostrar la cita
el
Mostrar la cita
que
Mostrar la cita
si
Mostrar la cita
si
Mostrar la cita
x
Mostrar la cita
#7 Maxi
22/08/2005 - 20:53 | Informe spam
Si tienes razon, pero si puedo asegurarlo de otra menera mejor ;-) de todas
formas los triggers los uso y bastante :-)


Salu2
Maxi


"Gustavo Larriera [MVP]" escribió en el mensaje
news:%
Mostrar la cita
#8 Maxi
22/08/2005 - 20:54 | Informe spam
Si y es muy simple de usar, a la vez es bastante optima


Salu2
Maxi


"Developers" escribió en el mensaje
news:
Mostrar la cita
#9 Alejandro Mesa
22/08/2005 - 21:19 | Informe spam
Maxi,

Mostrar la cita
Me parece que esta justificacion es un poco barata. Las vistas indexadas se
pueden borrar y no por eso dejan de ser un metodo mas. Si nos basamos en lo
anterior, entonces nada es garantizado 100% en sql server. Para eso existe el
role de dba, para eso existe una arquitectura de seguridad.

Las vistas indexadas son duda una magnifica herramienta, pero tambien tienen
muchas limitaciones (Ver "Requirements for the View" bajo "Creating an
Indexed View" en los libros en linea), las cuales no voy a enumerar del todo
porque son muchas.

- Consumen espacio en disco, ademas de tiempo cuando se actualizan las
tablas bases, por lo que se recomiendan solo cuando los beneficios de la
operacion de lectura sobre pasa ampliamente la tarea siempre en incremento de
sincronizar la data en ellas almacenada.

- No puede referenciar otras vistas, solo tablas bases.

- Todas las tablas referenciadas deben estar en la misma bd que la vista y
deben tener el mismo dueño que la vista.

- La sentencia "select" no puede usar tablas derivadas, subqueries, operador
"union", asi como outer o self joins.

- Todas las funciones referenciadas por la vista deben ser deterministas.

Se pueden crear vistas indexadas en otras versiones de sql server 2000, pero
el optimizador de query no las toma en cuenta de forma automatica si la
version no es "enterprise" y se debera usar el modificador NOEXPAND cuando
estas son referenciadas en una sentencia "select".

Como siempre, cada solucion debe ser probada y si sus resultados son los
adecuados pues ni hablar.


Alejandro Mesa

"Maxi" wrote:

Mostrar la cita
#10 Maxi
22/08/2005 - 21:31 | Informe spam
jaja!! no queria q suene barato el comentario ;-) es verdad lo que indicas,
lo que yo pienso es que los triggers son de mucha molestia en muchos casos,
hay que mantenerlos, si no estan bien pensados pueden hacer desastres con
el. Yo no es que no utilice trigger, los uso y bastante te diria, pero en mi
experiencia es que mientras menos los pueda usar mejor.
Ahora tambien sabes que hay otros problemas, por ej: un BCP o DTS podria
omitir los desencadenadores con lo cual hay que tener mucho pero mucho
cuidado, si todo esto se tiene bajo control

Te copio un texto de los BOL

Cuando se copian datos en una tabla, los desencadenadores definidos para la
tabla se pasan por alto.

Para buscar las filas que infringen restricciones o desencadenadores, debe
comprobar manualmente los datos copiados mediante consultas. Copie datos de
forma masiva en la tabla y ejecute consultas o procedimientos almacenados
que prueben las condiciones de las restricciones y los desencadenadores,
como:

UPDATE pubs..authors2 SET au_fname = au_fname
Aunque esta consulta no cambia valores de los datos, hace que Microsoft® SQL
ServerT actualice cada valor de la columna au_fname. Esto también causa que
se prueben las restricciones y los desencadenadores.


Un abrazo

Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:
Mostrar la cita
Ads by Google
Search Busqueda sugerida