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

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:
> Maxi,
>
>> digo esto, pues bien: los triggers se pueden deshabilitar y eso traeria
>> inconsistencias, ademas de armar triggers para estas cosas no es simple
>
> 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:
>
>> Hola Ale, hay que alertar de una cosa: si usas triggers no hay forma de
>> asegurar 100% que las cosas queden bien en la cabecera del articulo,
>> porque
>> digo esto, pues bien: los triggers se pueden deshabilitar y eso traeria
>> inconsistencias, ademas de armar triggers para estas cosas no es simple
>> (tampoco complejo claro)
>>
>>
>> Salu2
>> Maxi
>>
>>
>> "Alejandro Mesa" escribió en el
>> mensaje news:
>> > Deberias probar ambas soluciones antes de decidir. Si para la empresa
>> > es
>> > mas
>> > importante el tiempo de respuesta de las consultas, entonces escogeria
>> > la
>> > primera opcion (ojo, ese valor te da el corriente o ultimo. Para
>> > calcular
>> > este valor en tiempo pasado, debes recurrir al segundo metodo). Si por
>> > el
>> > contrario, tu empresa requiere mejor tiempo de respuesta durante el
>> > ingreso
>> > de transacciones, el segundo metodo seria perfecto al menos que el
>> > primero
>> > brinde un tiempo dentro de lo aceptado.
>> >
>> >
>> > AMB
>> >
>> > "Developers" wrote:
>> >
>> >> 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
>> >>
>> >>
>> >>
>>
>>
>>

Maxi,

Tambien las restricciones CHECK son deshabilitadas por defecto durante una
insercion en masa y no por ello dejamos de usarlas como parte del esquema
de
la bd.

Acepto que un trigger mal elaborado puede traer serios problemas, como
tambien los puede taer una funcion de usuario o un procedimiento
almacenado.
Que los triggers hacen la transaccion mas pesada y duradera, es verdad y
lo
mismo pasa con las vistas indexadas. Pero que son utiles cuando los usamos
de
manera correcta, tambien es verdad. No puedes, por ejemplo, mantener un
log
de los cambios sobre la data usando una vista indexada. Todo debe
estudiarse,
planificarse y ser probado. No debe usarse como escudo el absolutismo. Los
cursores son malos, es verdad, pero habre los procedimientos de la bd
[master] y veras que el propio "Microsoft" los usa cuando es necesario.

use master

select
routine_name
from
information_schema.routines
where
routine_type = 'procedure'
and patindex('%declare % cursor %', routine_definition) > 0
go

Existen pros y contras tanto para el uso de triggers, cursores, etc., como
para el uso de vistas indexadas.

Cual metodo usar?. Creo que a veces la respuesta a esta pregunta puede ser
simple, pero otras veces no. La mayoria de las veces termino con la misma
recomendacion, que es:

Probar, hacer test y escojer lo que mejor se adapte a sus necesidades.


AMB

"Maxi" wrote:

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:
> Maxi,
>
>> digo esto, pues bien: los triggers se pueden deshabilitar y eso
>> traeria
>> inconsistencias, ademas de armar triggers para estas cosas no es
>> simple
>
> 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:
>
>> Hola Ale, hay que alertar de una cosa: si usas triggers no hay forma
>> de
>> asegurar 100% que las cosas queden bien en la cabecera del articulo,
>> porque
>> digo esto, pues bien: los triggers se pueden deshabilitar y eso
>> traeria
>> inconsistencias, ademas de armar triggers para estas cosas no es
>> simple
>> (tampoco complejo claro)
>>
>>
>> Salu2
>> Maxi
>>
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > Deberias probar ambas soluciones antes de decidir. Si para la
>> > empresa
>> > es
>> > mas
>> > importante el tiempo de respuesta de las consultas, entonces
>> > escogeria
>> > la
>> > primera opcion (ojo, ese valor te da el corriente o ultimo. Para
>> > calcular
>> > este valor en tiempo pasado, debes recurrir al segundo metodo). Si
>> > por
>> > el
>> > contrario, tu empresa requiere mejor tiempo de respuesta durante el
>> > ingreso
>> > de transacciones, el segundo metodo seria perfecto al menos que el
>> > primero
>> > brinde un tiempo dentro de lo aceptado.
>> >
>> >
>> > AMB
>> >
>> > "Developers" wrote:
>> >
>> >> 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
>> >>
>> >>
>> >>
>>
>>
>>

Ale, coincidimos 100% opino igual q tu, y uso mucho los triggers como te

comentado, yo no digo de no usarlos, solo alerto de todos los problemas q
eso puede tener, si se puede sin trigger para mi es mejor, pero hay casos
donde no queda otra o donde el trigger es la mejor solucion, es como bien
vos decis, no hay blancos ni negros, tambien hay grises :-), tambien opino
igual q tu de los cursores y todo el resto, solo q hay q tener cuidado,

lo general son pocos los que los usan con criterio todas estas cosas,
entonces luego te encuentras con cada cosa que mejor ni hablar!! Hay veces
que se piesa hacerlo facil y no se ve todo el resto y ahi es donde podemos
tener serios problemas, por eso mi recomendacion de que tanto:

Triggers
Cursores
Tablas Temporales
(Indices)

Sean muy bien estudiados y antes de implementarlos como formula magica

todo (ya sea por facilidad o por lo que fuere) que se sepan bien los pros

contras y que ademas se tengan otras alternativas (en este caso como las
vistas indexadas).

Un abrazo!!


Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:
> Maxi,
>
> Tambien las restricciones CHECK son deshabilitadas por defecto durante

> insercion en masa y no por ello dejamos de usarlas como parte del

> de
> la bd.
>
> Acepto que un trigger mal elaborado puede traer serios problemas, como
> tambien los puede taer una funcion de usuario o un procedimiento
> almacenado.
> Que los triggers hacen la transaccion mas pesada y duradera, es verdad y
> lo
> mismo pasa con las vistas indexadas. Pero que son utiles cuando los

> de
> manera correcta, tambien es verdad. No puedes, por ejemplo, mantener un
> log
> de los cambios sobre la data usando una vista indexada. Todo debe
> estudiarse,
> planificarse y ser probado. No debe usarse como escudo el absolutismo.

> cursores son malos, es verdad, pero habre los procedimientos de la bd
> [master] y veras que el propio "Microsoft" los usa cuando es necesario.
>
> use master
>
> select
> routine_name
> from
> information_schema.routines
> where
> routine_type = 'procedure'
> and patindex('%declare % cursor %', routine_definition) > 0
> go
>
> Existen pros y contras tanto para el uso de triggers, cursores, etc.,

> para el uso de vistas indexadas.
>
> Cual metodo usar?. Creo que a veces la respuesta a esta pregunta puede

> simple, pero otras veces no. La mayoria de las veces termino con la

> recomendacion, que es:
>
> Probar, hacer test y escojer lo que mejor se adapte a sus necesidades.
>
>
> AMB
>
> "Maxi" wrote:
>
>> 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

>> el. Yo no es que no utilice trigger, los uso y bastante te diria, pero

>> mi
>> experiencia es que mientras menos los pueda usar mejor.
>> Ahora tambien sabes que hay otros problemas, por ej: un BCP o DTS

>> 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

>> la
>> tabla se pasan por alto.
>>
>> Para buscar las filas que infringen restricciones o desencadenadores,
>> debe
>> comprobar manualmente los datos copiados mediante consultas. Copie

>> de
>> forma masiva en la tabla y ejecute consultas o procedimientos

>> que prueben las condiciones de las restricciones y los

>> como:
>>
>> UPDATE pubs..authors2 SET au_fname = au_fname
>> Aunque esta consulta no cambia valores de los datos, hace que

>> 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

>> mensaje news:
>> > Maxi,
>> >
>> >> digo esto, pues bien: los triggers se pueden deshabilitar y eso
>> >> traeria
>> >> inconsistencias, ademas de armar triggers para estas cosas no es
>> >> simple
>> >
>> > 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

>> > Indexed View" en los libros en linea), las cuales no voy a enumerar

>> > todo
>> > porque son muchas.
>> >
>> > - Consumen espacio en disco, ademas de tiempo cuando se actualizan

>> > 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

>> > pero
>> > el optimizador de query no las toma en cuenta de forma automatica si

>> > 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:
>> >
>> >> Hola Ale, hay que alertar de una cosa: si usas triggers no hay forma
>> >> de
>> >> asegurar 100% que las cosas queden bien en la cabecera del articulo,
>> >> porque
>> >> digo esto, pues bien: los triggers se pueden deshabilitar y eso
>> >> traeria
>> >> inconsistencias, ademas de armar triggers para estas cosas no es
>> >> simple
>> >> (tampoco complejo claro)
>> >>
>> >>
>> >> Salu2
>> >> Maxi
>> >>
>> >>
>> >> "Alejandro Mesa" escribió

>> >> el
>> >> mensaje news:
>> >> > Deberias probar ambas soluciones antes de decidir. Si para la
>> >> > empresa
>> >> > es
>> >> > mas
>> >> > importante el tiempo de respuesta de las consultas, entonces
>> >> > escogeria
>> >> > la
>> >> > primera opcion (ojo, ese valor te da el corriente o ultimo. Para
>> >> > calcular
>> >> > este valor en tiempo pasado, debes recurrir al segundo metodo). Si
>> >> > por
>> >> > el
>> >> > contrario, tu empresa requiere mejor tiempo de respuesta durante

>> >> > ingreso
>> >> > de transacciones, el segundo metodo seria perfecto al menos que el
>> >> > primero
>> >> > brinde un tiempo dentro de lo aceptado.
>> >> >
>> >> >
>> >> > AMB
>> >> >
>> >> > "Developers" wrote:
>> >> >
>> >> >> 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

>> >> >> almacen.
>> >> >> Tengo Varias Dudas que detallo a continuacion.
>> >> >>
>> >> >> 1.- Usar Triggers para la Insercion,Eliminacion o Actualizacion

>> >> >> 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

>> >> >> de
>> >> >> la
>> >> >> Tabla movimiento.(Aclaro que la Empresa tiene movimientos Grande

>> >> >> 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

>> >> >> 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
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

Y Yo solo pregunte por algunas opiniones respecto al Control de Stocks y me
encuentro con Hilos de Hilos de conversiones bastantes interasantes.

Gracias ambos x los consejos y esperemos que lo tengamos siempre para
aclarar dudas.


Developers


"Maxi" escribió en el mensaje
news:

Ale, coincidimos 100% opino igual q tu, y uso mucho los triggers como te

he

comentado, yo no digo de no usarlos, solo alerto de todos los problemas q
eso puede tener, si se puede sin trigger para mi es mejor, pero hay casos
donde no queda otra o donde el trigger es la mejor solucion, es como bien
vos decis, no hay blancos ni negros, tambien hay grises :-), tambien
opino
igual q tu de los cursores y todo el resto, solo q hay q tener cuidado,

por

lo general son pocos los que los usan con criterio todas estas cosas,
entonces luego te encuentras con cada cosa que mejor ni hablar!! Hay
veces
que se piesa hacerlo facil y no se ve todo el resto y ahi es donde
podemos
tener serios problemas, por eso mi recomendacion de que tanto:

Triggers
Cursores
Tablas Temporales
(Indices)

Sean muy bien estudiados y antes de implementarlos como formula magica

para

todo (ya sea por facilidad o por lo que fuere) que se sepan bien los pros

y

contras y que ademas se tengan otras alternativas (en este caso como las
vistas indexadas).

Un abrazo!!


Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:
> Maxi,
>
> Tambien las restricciones CHECK son deshabilitadas por defecto durante

una

> insercion en masa y no por ello dejamos de usarlas como parte del

esquema

> de
> la bd.
>
> Acepto que un trigger mal elaborado puede traer serios problemas, como
> tambien los puede taer una funcion de usuario o un procedimiento
> almacenado.
> Que los triggers hacen la transaccion mas pesada y duradera, es verdad
> y
> lo
> mismo pasa con las vistas indexadas. Pero que son utiles cuando los

usamos

> de
> manera correcta, tambien es verdad. No puedes, por ejemplo, mantener un
> log
> de los cambios sobre la data usando una vista indexada. Todo debe
> estudiarse,
> planificarse y ser probado. No debe usarse como escudo el absolutismo.

Los

> cursores son malos, es verdad, pero habre los procedimientos de la bd
> [master] y veras que el propio "Microsoft" los usa cuando es necesario.
>
> use master
>
> select
> routine_name
> from
> information_schema.routines
> where
> routine_type = 'procedure'
> and patindex('%declare % cursor %', routine_definition) > 0
> go
>
> Existen pros y contras tanto para el uso de triggers, cursores, etc.,

como

> para el uso de vistas indexadas.
>
> Cual metodo usar?. Creo que a veces la respuesta a esta pregunta puede

ser

> simple, pero otras veces no. La mayoria de las veces termino con la

misma

> recomendacion, que es:
>
> Probar, hacer test y escojer lo que mejor se adapte a sus necesidades.
>
>
> AMB
>
> "Maxi" wrote:
>
>> 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:
>> > Maxi,
>> >
>> >> digo esto, pues bien: los triggers se pueden deshabilitar y eso
>> >> traeria
>> >> inconsistencias, ademas de armar triggers para estas cosas no es
>> >> simple
>> >
>> > 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:
>> >
>> >> Hola Ale, hay que alertar de una cosa: si usas triggers no hay
>> >> forma
>> >> de
>> >> asegurar 100% que las cosas queden bien en la cabecera del
>> >> articulo,
>> >> porque
>> >> digo esto, pues bien: los triggers se pueden deshabilitar y eso
>> >> traeria
>> >> inconsistencias, ademas de armar triggers para estas cosas no es
>> >> simple
>> >> (tampoco complejo claro)
>> >>
>> >>
>> >> Salu2
>> >> Maxi
>> >>
>> >>
>> >> "Alejandro Mesa" escribió

en

>> >> el
>> >> mensaje news:
>> >> > Deberias probar ambas soluciones antes de decidir. Si para la
>> >> > empresa
>> >> > es
>> >> > mas
>> >> > importante el tiempo de respuesta de las consultas, entonces
>> >> > escogeria
>> >> > la
>> >> > primera opcion (ojo, ese valor te da el corriente o ultimo. Para
>> >> > calcular
>> >> > este valor en tiempo pasado, debes recurrir al segundo metodo).
>> >> > Si
>> >> > por
>> >> > el
>> >> > contrario, tu empresa requiere mejor tiempo de respuesta durante

el

>> >> > ingreso
>> >> > de transacciones, el segundo metodo seria perfecto al menos que
>> >> > el
>> >> > primero
>> >> > brinde un tiempo dentro de lo aceptado.
>> >> >
>> >> >
>> >> > AMB
>> >> >
>> >> > "Developers" wrote:
>> >> >
>> >> >> 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
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

En mi humilde opinión, la deshabilitación de triggers es una situación muy
específica y reservada para uso exclusivo del DBA. No debe considerarse
una situación de operativa normal de trabajo, caso contrario jamás
usaríamos triggers y sería mejor que no existieran o que no pudieran
deshabilitarse :-)