Programar recursividad

07/10/2006 - 03:16 por Jose Camacho Vaca | Informe spam
Un favor, a ver si me pueden ayudar un poco en este problema. Tenemos una
aplicación contable hecha en visual foxpro trabajando sobre SQL2000, por el
momento trabaja bien, pero tenemos algunos problemas de velocidad debido a
que el sistema hace algunas actualizaciones en base a una función recursiva.
La función lo que hace es lo siguiente:

actualiza los saldos de una cuenta en base al cargo o al abono que se le
mande y si la cuenta pertenece a otra (es decir es hija de una cuenta padre)
actualiza los saldos de su cuenta padre en base al cargo o al abono que se le
haya hecho a la cuenta hija y si esta a su vez es cuenta hija de otra pues
hace exactamente lo mismo. La recursividad termina cuando se encuentra una
cuenta que no tiene cuenta padre.

el problema que estoy viendo es que con el crecimiento de la información y
de las cuentas es muy probable que el rendimiento baje y lo que quisiera
hacer es pasar ese proceso de actualización recursiva hacia un store
procedure en el servidor SQL.

Bueno, creo que eso es todo, cualquier sugerencia se los agradecería mucho.

Reciban un cordial saludo.

José Camacho Vaca
Colima, mx.

Preguntas similare

Leer las respuestas

#1 Maxi
07/10/2006 - 13:29 | Informe spam
Hola, el tema de recursividad en sql2000 no es tan sencillo como en 2005
pero de todas maneras algo de rendimiento mas se le puede sacar. Habria que
analizar bien tu caso y ver las tablas, los indices, las consultas como para
ver como optimizarla


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
"Jose Camacho Vaca" wrote in
message news:
Un favor, a ver si me pueden ayudar un poco en este problema. Tenemos una
aplicación contable hecha en visual foxpro trabajando sobre SQL2000, por
el
momento trabaja bien, pero tenemos algunos problemas de velocidad debido a
que el sistema hace algunas actualizaciones en base a una función
recursiva.
La función lo que hace es lo siguiente:

actualiza los saldos de una cuenta en base al cargo o al abono que se le
mande y si la cuenta pertenece a otra (es decir es hija de una cuenta
padre)
actualiza los saldos de su cuenta padre en base al cargo o al abono que se
le
haya hecho a la cuenta hija y si esta a su vez es cuenta hija de otra pues
hace exactamente lo mismo. La recursividad termina cuando se encuentra
una
cuenta que no tiene cuenta padre.

el problema que estoy viendo es que con el crecimiento de la información y
de las cuentas es muy probable que el rendimiento baje y lo que quisiera
hacer es pasar ese proceso de actualización recursiva hacia un store
procedure en el servidor SQL.

Bueno, creo que eso es todo, cualquier sugerencia se los agradecería
mucho.

Reciban un cordial saludo.

José Camacho Vaca
Colima, mx.
Respuesta Responder a este mensaje
#2 Ricardo Passians
07/10/2006 - 17:05 | Informe spam
Jose:

Para eso lo más indicado sería usar triggers (la definición sería recursiva
de por si) pero debes tener claro que te ralentiza las actualizaciones
mientras más hijas tenga una cuenta. En sistemas donde lo más frecuente es
el registro de transacciones que las consultas deberías sopesar bien eso.

Algunos tips sobre ese modelo:
Deberías evaluar la posibilidad de sólo tener 'sumados' los balances de las
cuentas auxiliares (los nodos finales del arbol), que son las que llevan las
transacciones realmente. Si decides hacerlo así, una vista indexada de
cuentas por meses sería más que apropiada.
Luego, la recursividad la dejarías para las consultas, cuando se solicite un
balance una cuenta que tenga hijas.
Aunque, si configuras los códigos de las cuentas estrictamente en estructura
de árbol, verás lo fácil, sin recursividad que sería calcular el balance de
una cuenta, sumando los balances de todas sus auxiliares no importa al nivel
que estén, asumido que solo se almacenan los balances de las auxiliares de
nivel inferior.


Ricardo Passians
"Jose Camacho Vaca" escribió en
el mensaje news:
Un favor, a ver si me pueden ayudar un poco en este problema. Tenemos una
aplicación contable hecha en visual foxpro trabajando sobre SQL2000, por
el
momento trabaja bien, pero tenemos algunos problemas de velocidad debido a
que el sistema hace algunas actualizaciones en base a una función
recursiva.
La función lo que hace es lo siguiente:

actualiza los saldos de una cuenta en base al cargo o al abono que se le
mande y si la cuenta pertenece a otra (es decir es hija de una cuenta
padre)
actualiza los saldos de su cuenta padre en base al cargo o al abono que se
le
haya hecho a la cuenta hija y si esta a su vez es cuenta hija de otra pues
hace exactamente lo mismo. La recursividad termina cuando se encuentra
una
cuenta que no tiene cuenta padre.

el problema que estoy viendo es que con el crecimiento de la información y
de las cuentas es muy probable que el rendimiento baje y lo que quisiera
hacer es pasar ese proceso de actualización recursiva hacia un store
procedure en el servidor SQL.

Bueno, creo que eso es todo, cualquier sugerencia se los agradecería
mucho.

Reciban un cordial saludo.

José Camacho Vaca
Colima, mx.
Respuesta Responder a este mensaje
#3 Jose Camacho Vaca
10/10/2006 - 19:22 | Informe spam
Muchisimas gracias a ambos por su ayuda, realmente veo que este es un tema
muy extenso. Dos puntos en mi contra son que los datos de las cuentas de
mayor normalmente se ocupan actualizados en linea, inclusive hay un monitoreo
de las mismas, y el segundo punto es que desafortunadamente diseñamos todo el
sistema para trabajar con objeto (POO) y en realidad lo que hacemos es
instanciar objetos recursivamente.

Si ustedes me lo permite les pudiera mandar los ejemplos de código en VFP y
un script de la bases de datos para que pudieran visualizar mejor el
problema. Hasta donde yo se no existe POO en T-SQL pero creo que algo se
pudiera hacer, tal vez inclusive migrando a SQL2005.

Gracias por su ayuda nuevamente y reciban un saludo.
Atte.
José Camacho Vaca
Colima, MX.

"Ricardo Passians" wrote:

Jose:

Para eso lo más indicado sería usar triggers (la definición sería recursiva
de por si) pero debes tener claro que te ralentiza las actualizaciones
mientras más hijas tenga una cuenta. En sistemas donde lo más frecuente es
el registro de transacciones que las consultas deberías sopesar bien eso.

Algunos tips sobre ese modelo:
Deberías evaluar la posibilidad de sólo tener 'sumados' los balances de las
cuentas auxiliares (los nodos finales del arbol), que son las que llevan las
transacciones realmente. Si decides hacerlo así, una vista indexada de
cuentas por meses sería más que apropiada.
Luego, la recursividad la dejarías para las consultas, cuando se solicite un
balance una cuenta que tenga hijas.
Aunque, si configuras los códigos de las cuentas estrictamente en estructura
de árbol, verás lo fácil, sin recursividad que sería calcular el balance de
una cuenta, sumando los balances de todas sus auxiliares no importa al nivel
que estén, asumido que solo se almacenan los balances de las auxiliares de
nivel inferior.


Ricardo Passians
"Jose Camacho Vaca" escribió en
el mensaje news:
> Un favor, a ver si me pueden ayudar un poco en este problema. Tenemos una
> aplicación contable hecha en visual foxpro trabajando sobre SQL2000, por
> el
> momento trabaja bien, pero tenemos algunos problemas de velocidad debido a
> que el sistema hace algunas actualizaciones en base a una función
> recursiva.
> La función lo que hace es lo siguiente:
>
> actualiza los saldos de una cuenta en base al cargo o al abono que se le
> mande y si la cuenta pertenece a otra (es decir es hija de una cuenta
> padre)
> actualiza los saldos de su cuenta padre en base al cargo o al abono que se
> le
> haya hecho a la cuenta hija y si esta a su vez es cuenta hija de otra pues
> hace exactamente lo mismo. La recursividad termina cuando se encuentra
> una
> cuenta que no tiene cuenta padre.
>
> el problema que estoy viendo es que con el crecimiento de la información y
> de las cuentas es muy probable que el rendimiento baje y lo que quisiera
> hacer es pasar ese proceso de actualización recursiva hacia un store
> procedure en el servidor SQL.
>
> Bueno, creo que eso es todo, cualquier sugerencia se los agradecería
> mucho.
>
> Reciban un cordial saludo.
>
> José Camacho Vaca
> Colima, mx.



email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida