Sistema de stock, cual es la manera de diseniarlo ?

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

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

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

Esto no es cierto, va, hasta el sp2 era cierto, pero desde el sp3a se pueden
usar en cualquier version (incluida la STD y MSDE)
Eso si, en los BOL no lo actualizaron pero es un error de documentacion.

Hola Ale, es cierto lo que indicas en parte de las vistas, pero en este tipo
de modelos te puedo asegurar que son excelentes. Nuestra tabla de
transacciones tiene mas de 5.000.000 de registros y no sabes lo agil que
son. Ahora una correcion:

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

Esto no es cierto, va, hasta el sp2 era cierto, pero desde el sp3a se pueden
usar en cualquier version (incluida la STD y MSDE)
Eso si, en los BOL no lo actualizaron pero es un error de documentacion.




Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:
> 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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>

Maxi,

Solo quize extender un poquito mas lo de las vistas indexadas. Si la
cantidad de transacciones por stock (insert / update / delete) es muy
alta,
indiscutiblemente que tener una vista indexada influira muchisimo en la
performance de la bd. Esto debe ser probado y si el resultado esta dentro
de
los parametros de la aplicacion, pues ni hablar.

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

Esto no es cierto, va, hasta el sp2 era cierto, pero desde el sp3a se
pueden
usar en cualquier version (incluida la STD y MSDE)
Eso si, en los BOL no lo actualizaron pero es un error de documentacion.

Al parecer he estado durmiendo por un buen rato.

Gracias por la info. Me alegra mucho que Microsoft haya extendido esta
facilidad de sql server 2000 hacia todas sus versiones.


AMB

"Maxi" wrote:

Hola Ale, es cierto lo que indicas en parte de las vistas, pero en este
tipo
de modelos te puedo asegurar que son excelentes. Nuestra tabla de
transacciones tiene mas de 5.000.000 de registros y no sabes lo agil que
son. Ahora una correcion:

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

Esto no es cierto, va, hasta el sp2 era cierto, pero desde el sp3a se
pueden
usar en cualquier version (incluida la STD y MSDE)
Eso si, en los BOL no lo actualizaron pero es un error de documentacion.




Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:
> 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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>

Gracias Ale, !! siempre es muy bueno compartir contigo estos temas :-)
lastima que estemos tan lejos :(


Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:
> Maxi,
>
> Solo quize extender un poquito mas lo de las vistas indexadas. Si la
> cantidad de transacciones por stock (insert / update / delete) es muy
> alta,
> indiscutiblemente que tener una vista indexada influira muchisimo en la
> performance de la bd. Esto debe ser probado y si el resultado esta dentro
> de
> los parametros de la aplicacion, pues ni hablar.
>
>> > Una ultima cosita, para crear vistas indexadas se necesita las
>> > versiones
>> > Enterprise / Developer de sql server 2000.
>> >
>>
>> Esto no es cierto, va, hasta el sp2 era cierto, pero desde el sp3a se
>> pueden
>> usar en cualquier version (incluida la STD y MSDE)
>> Eso si, en los BOL no lo actualizaron pero es un error de documentacion.
>
> Al parecer he estado durmiendo por un buen rato.
>
> Gracias por la info. Me alegra mucho que Microsoft haya extendido esta
> facilidad de sql server 2000 hacia todas sus versiones.
>
>
> AMB
>
> "Maxi" wrote:
>
>> Hola Ale, es cierto lo que indicas en parte de las vistas, pero en este
>> tipo
>> de modelos te puedo asegurar que son excelentes. Nuestra tabla de
>> transacciones tiene mas de 5.000.000 de registros y no sabes lo agil que
>> son. Ahora una correcion:
>>
>> > Una ultima cosita, para crear vistas indexadas se necesita las
>> > versiones
>> > Enterprise / Developer de sql server 2000.
>> >
>>
>> Esto no es cierto, va, hasta el sp2 era cierto, pero desde el sp3a se
>> pueden
>> usar en cualquier version (incluida la STD y MSDE)
>> Eso si, en los BOL no lo actualizaron pero es un error de documentacion.
>>
>>
>>
>>
>> Salu2
>> Maxi
>>
>>
>> "Alejandro Mesa" escribió en el
>> mensaje news:
>> > 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
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

Maxi,

Cada vez que veo un mensaje con el titulo "[OT] Evento Gratuito en Buenos
Aires, Argentina", la inmaginación no me deja trabajar.

Saludos,

AMB

"Maxi" wrote:

Gracias Ale, !! siempre es muy bueno compartir contigo estos temas :-)
lastima que estemos tan lejos :(


Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:
> Maxi,
>
> Solo quize extender un poquito mas lo de las vistas indexadas. Si la
> cantidad de transacciones por stock (insert / update / delete) es muy
> alta,
> indiscutiblemente que tener una vista indexada influira muchisimo en la
> performance de la bd. Esto debe ser probado y si el resultado esta
> dentro
> de
> los parametros de la aplicacion, pues ni hablar.
>
>> > Una ultima cosita, para crear vistas indexadas se necesita las
>> > versiones
>> > Enterprise / Developer de sql server 2000.
>> >
>>
>> Esto no es cierto, va, hasta el sp2 era cierto, pero desde el sp3a se
>> pueden
>> usar en cualquier version (incluida la STD y MSDE)
>> Eso si, en los BOL no lo actualizaron pero es un error de
>> documentacion.
>
> Al parecer he estado durmiendo por un buen rato.
>
> Gracias por la info. Me alegra mucho que Microsoft haya extendido esta
> facilidad de sql server 2000 hacia todas sus versiones.
>
>
> AMB
>
> "Maxi" wrote:
>
>> Hola Ale, es cierto lo que indicas en parte de las vistas, pero en
>> este
>> tipo
>> de modelos te puedo asegurar que son excelentes. Nuestra tabla de
>> transacciones tiene mas de 5.000.000 de registros y no sabes lo agil
>> que
>> son. Ahora una correcion:
>>
>> > Una ultima cosita, para crear vistas indexadas se necesita las
>> > versiones
>> > Enterprise / Developer de sql server 2000.
>> >
>>
>> Esto no es cierto, va, hasta el sp2 era cierto, pero desde el sp3a se
>> pueden
>> usar en cualquier version (incluida la STD y MSDE)
>> Eso si, en los BOL no lo actualizaron pero es un error de
>> documentacion.
>>
>>
>>
>>
>> Salu2
>> Maxi
>>
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > 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
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>