Columna Saldo de Cuenta Corriente

On 13 jul, 15:36, "principiante" wrote:

> voy a analizarlas para ver que opción tomar
> la opción de presentarlo directamente en el Front-End es la que vengo
> usando hace mucho tiempo, solo quería ver si había algo mejor

La mejor manera es revisar los planes de ejecucion de las opciones que te
han dado para ver si realmente se justifica no hacerlo en el Front-End, como
parece ser lo mas adecuado aqui por lo costosa que pueden ser esas consultas
que envuelven subconsultas.

El hacerlo y no el 'no hacerlo' en el front-end necesita
justificación.
De todas formas esas consultas si son *muy* costosas, como también
lo sería llevarse todos los registros al front-end cuando solo se
quiere saber el saldo.
Otra alternativa sería calcular el saldo cuando se actualizan los
registros y no al consultar.

Saludos,
Carlos

El hacerlo y no el 'no hacerlo' en el front-end necesita
justificación.

Es tu opinion.
Yo creo que es lo contrario.

De todas formas esas consultas si son *muy* costosas, como también
lo sería llevarse todos los registros al front-end cuando solo se
quiere saber el saldo.

Para mi te equivocas. En otro de los mensajes otro participante (Ricardo)
explica el criterio que se emplearía y no se habla de llevarse todos los
registros al front-end, a eso no se le ocurriria ni al mas novato creo yo.
Lo que se hace es calcular solo el balance inicial antes de la primera
fecha. Luego en un reporte del front-end es solo sumar y restar con los
registros del rango (debe menos haber).

Otra alternativa sería calcular el saldo cuando se actualizan los
registros y no al consultar.

Opino que eso daria el problema de si se insertan fechas anteriores o se
modifican valores de los debe y haber habria que recalcular todo hacia
adelante.
Para mi seria todavia peor.

Saludos

Jose TH

Para mi te equivocas. En otro de los mensajes otro participante (Ricardo)
explica el criterio que se emplearía y no se habla de llevarse todos los
registros al front-end, a eso no se le ocurriria ni al mas novato creo yo.
Lo que se hace es calcular solo el balance inicial antes de la primera
fecha. Luego en un reporte del front-end es solo sumar y restar con los
registros del rango (debe menos haber).

Aclarando, en cualquiera de los métodos que se utilice los registros dentro
del rango de fechas indicado lógicamente serán traídos al front-end porque
si no, cómo haríamos el reporte? Eso está claro; lo que sí sería
innecesario es traer "todos" los registros (como entendió el otro compañero)
de una tabla para hacer sólo el cálculo de un balance inicial, valor que
sería el único realmente necesario de calcular de la cuenta, porque el resto
como tú muy bien interpretaste lo haría un reporte secuencial del front-end
sólo sumando el balance anterior más el debe menos el haber registro por
registro.
Eso se armaría perfecto en un SP que aparte de devolverme el set de
registros dentro del rango de fechas, mandarle un parámetro Output para que
me devuelva allí el balance inicial antes de la primera fecha.
Asumiendo una sola cuenta claro pero para todas las cuentas o para un rango
de éstas se extendería el SP para que en vez de un parámetro tipo output me
devuelva otro set con los balances iniciales calculados para cada cuenta en
cuestión. Util por ejemplo esto último para imprimir un reporte de mayor
general de la contabilidad a un rango arbitrario de cuentas y de fechas.

Otra alternativa sería calcular el saldo cuando se actualizan los
registros y no al consultar.

Opino que eso daria el problema de si se insertan fechas anteriores o se
modifican valores de los debe y haber habria que recalcular todo hacia
adelante.
Para mi seria todavia peor.

Podría evaluarse quizás pero también creo que los triggers deberían evitarse
siempre que haya mejores opciones debido, entre otras importantes razones de
mantenimiento, a que ralentizan las actualizaciones.
No creo por tanto que esa opción sea conveniente tampoco en este caso.


Saludos

Ricardo Passians

devuelva otro set con los balances iniciales calculados para cada cuenta
en cuestión. Util por ejemplo esto último para imprimir un reporte de
mayor general de la contabilidad a un rango arbitrario de cuentas y de
fechas.

Es muy interesante ese tema y veo bien ese metodo porque por cierto en mi
empresa tenemos un sistema de conciliacion bancaria que al imprimir un
libro de bancos de una semana por ejemplo lo hacemos de esa manera y es muy
rapido y no son pocos datos, solo agregar que usamos otras tecnicas para
agilizar el calculo de los balances iniciales teniendo resumido hasta el año
anterior pero la idea es la misma.

Por supuesto que llegamos a esa conclusion no por arte de magia sino que
sufrimos pasar varios años viendo crecer los datos y con ellos la lentitud
de hacerlo con consultas parecidas a las expuestas en este hilo.

Mas que lo que dice el principiante yo creo que a veces no basta con ver
los planes de ejecucion sino tambien hacer las pruebas en produccion para
darse cuenta cuando una solucion puede ser mejor mas aun que los planes de
ejecucion no muestran como se comporta el cliente.


Bye

José Abreu

On 13 jul, 22:37, "principiante" wrote:

>El hacerlo y no el 'no hacerlo' en el front-end necesita
>justificación.

Es tu opinion.

El saldo es un dato. Y datos se le piden al SGBD, que es el
responsable de su integridad y su derivación. Un dato por
ser derivado no es menos dato y el cálculo que lo define
es la regla de integridad a cumplir, siempre; independientemente
que quién (usuarios, aplicaciones) y cómo (por medio de una
aplicación, ad hoc sql, etc.) se pida.

La funciones fundamentales de un SGBD son guardar la integridad
de datos, derivación de datos y centralizar y compartir los
estos datos y las reglas para su integridad y derivación.

Una opinión fundamentada entonces... y no solo mía.

Yo creo que es lo contrario.

Ya veo! :)

>De todas formas esas consultas si son *muy* costosas, como también
>lo sería llevarse todos los registros al front-end cuando solo se
>quiere saber el saldo.

Para mi te equivocas.

Dónde?

En otro de los mensajes otro participante (Ricardo)
explica el criterio que se emplearía y no se habla de llevarse todos los
registros al front-end, a eso no se le ocurriria ni al mas novato creo yo.
Lo que se hace es calcular solo el balance inicial antes de la primera
fecha. Luego en un reporte del front-end es solo sumar y restar con los
registros del rango (debe menos haber).

Cómo se calcula 'el balance inicial' para la primera fecha del rango
que se pide? (que puede ser cualquier fecha) Y dónde?
Cómo se calcula el saldo actual para un lista de cuentas? (por
ejemplo: no_cuenta, nombre, fecha_última_transación, saldo) Y dónde?
Cómo se calcula el saldo que tenían todas las cuentas, por
ejemplo, el 13 de octubre del 2002? Y dónde?
Algunos departamentos, con sus aplicaciones muy específicas, y
diversas, están muy interesados en una **variedad enorme** en este
tipo de preguntas y consultas.

>Otra alternativa sería calcular el saldo cuando se actualizan los
>registros y no al consultar.

Opino que eso daria el problema de si se insertan fechas anteriores o se
modifican valores de los debe y haber habria que recalcular todo hacia
adelante.
Para mi seria todavia peor.

No veo por qué eso sería peor que hacerlo en las aplicaciones.
O es un cálculo centralizado hecho solo una vez, mas lento que el
mismo cálculo decentralizado a, digamos 23 aplicaciones y calculado
1549 veces en un período de, digamos, 3 meses? Ya sin hablar de
programar y hacer el mantenimiento del cálculo una o 23 veces.
Y en algunas de estas aplicaciones el cálculo apararece en,
digamos, 7 sitios.

Además que eso no tiene por qué ser así. Si estamos hablando de
algo serio, esos son datos históricos. Y si ha habido algún fallo,
como hecho histórico tiene que quedar registrado, por ejemplo
porque ya ha sido comunicado al exterior, a clientes.
Se introduce entonces un nuevo movimiento representando una
corrección, que es otro hecho histórico.

En cuanto a escalabilidad y mantenimiento, cuando el cálculo
cambie (se introducen mas variables p.e.), o se tenga que corregir,
a ver que es lo que cuesta más (hablando de tiempo y eficiencia)...
Cambiar el cálculo centralizado (y las aplicaciones no se enteran
porque no se rompe la interfaz) o cambiar 23 aplicaciones a las que
a lo mejor no se tiene ni acceso y están desarrolladas en 8
lenguajes distintos y por otras tantas empresas.

Puedes proponerle a tu banco que a partir de hoy no quieres que el
el saldo de tus cuentas sea centralizado y compartido (calculado o
no), por las 23 aplicaciones que lo requieren. Que a partir de hoy
todas esas aplicaciones se resposabilizen de determinar cual es el
saldo de tus cuentas. Al final tus saldos dependerán de a qué
departamento (o aplicación) se le pregunte.

Saludos,
Carlos