Columna Saldo de Cuenta Corriente

On 14 jul, 04:51, "Jose Abreu" wrote:

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.

Bueno tu 'ves bien' ese método porque confirma tu expericencia.
Otras empresas... otra gente, pueden haberlo hecho de otra forma y
haber conseguido otro resultado, que también 'ven bien'.
Y ahora qué hacemos con eso? Experiencias las hay para todos
los gustos y en nuestra profesión casi nunca representan algo
fundamental.

Si cada movimento lleva consigo el saldo eso no hubiera sido
necesario. Es cálculo no tiene por qué costar tanto;
saldo anterior + saldo del último movimiento, vaya cosa!
Si se hace en triggers, vistas materializadas o como sea
ya es otro problema.

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.

Hay dos niveles aquí; primero determinar quien es el responsable en
el sistema de la integridad de un dato; después evaluar distintas
formas de hacerlo allí donde le corresponde y elegir lo mas
eficiente, sin romper la lógica del primer punto.
Lo primero parece no importaros. Entonces que evaluando solo lo
segundo lleguéis a las concusiones que llegáis no me parece
algo definitivo, ni mucho menos.

Mira también mi reacción a Principiante.

Saludos,
Carlos

On 13 jul, 23:20, "Ricardo Passians"
wrote:

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

He entidido mas que eso. Mira mis otras reacciones.

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.

O sea... que el cálculo de los saldos no solo se esparce por las
aplicaciones, sino que una parte es responsablidad del SGBD
y la otra de las aplicaciones. Parecéis maestros del caos :)

Saludos,
Carlos

O sea... que el cálculo de los saldos no solo se esparce por las
aplicaciones, sino que una parte es responsablidad del SGBD
y la otra de las aplicaciones. Parecéis maestros del caos :)

Es muy correcta la idea de lo que dices en ese párrafo en cuanto a que
debemos siempre traer los datos desde el servidor. Aunque en este caso yo me
he enfocado a la eficiencia, tema que en algun caso muy específico como éste
nos puede sugerir romper ciertas reglas. Pero nunca llevar a un caos de
descentralización y pérdida de integridad.

Pero de todos modos depende cómo lo veas para este ejemplo, ya que el
balance inicial siempre vendría calculado desde el servidor. En el peor de
los casos hasta podrías traer calculado desde el servidor también el balance
final. El resto es presentación en el reporte.
Pero aunque estoy casi seguro que es la más eficiente, no es la única
manera de hacerlo; en otro mensaje di otra forma de hacerlo con una tabla
temporal que le deja menos libertad al front-end, que es lo que tú apuntas
con mucha razón.

Saludos

Ricardo Passians

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

Es tu opinion.

El saldo es un dato.

Para mi es un calculo, por lo que ya empezamos mal partiendo de supuestos
distintos.

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.

Segun tu, un total de ventas de un reporte, solo para poner otro ejemplo,
también es un dato y dime tu si también lo traes del servidor.
Si es así pues pues parece que programas la aplicacion en el servidor.
Para que son los generadores de reportes entonces si no podemos hacer sumas
y restas?
O respondeme entonces que es lo que tu haces en los generadores de reportes
que tienen valores?

Mira el ejemplo ayer justamente un cliente me pide un reporte de movimientos
de stock entre fechas pero me pide que le totalice las entradas y salidas
por dia para el verlo de esa forma aparte de detallado. Estos totales
tambien son datos, no es asi?
Si el reporte (sql reporting) me hace eso, por que voy a cargar el servidor
con ese calculo que me lo hace el generador de reportes?

Ahora bien si eso preocupa mucho, estos reportes se prediseñan en una capa
de negocios tambien centralizada.

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.

No se quien esta discutiendo eso en este tema particular que estamos
debatiendo.

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

Cómo que dónde? Acabas de decir que para calcular el saldo de la forma que
estamos hablando es "llevarse todos los registros al front-end". A quien
se le ocurre suponer eso?

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)

Bueno yo no fui quien propuso el ejemplo pero para mi es una simple suma:

ej. select sum(debe-haber) from transacciones where cuenta='numerocuenta'
and fecha<'primerafecha'

Y mejoraria mucho si tuvieramos una vista indexada con los totales por mes
ya acumulados y solo agregarle los movimientos del mes de la fecha
indicado.. Que te parece?

Y dónde?

Por supuesto que en el servidor.

Cómo se calcula el saldo actual para un lista de cuentas? (por
ejemplo: no_cuenta, nombre, fecha_última_transación, saldo)

Leete los mensajes de Ricardo Passian que ahi tienes mas detalles. Debiste
empezar por ahi y no hacerme esas preguntas a mi.

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?

De la misma manera y el mismo sitio: el servidor.

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.

Y? no veo cual es tu punto ya que cada aplicacion siempre hara con los
datos lo que sus programadores decidan, ya eso es responsabilidad de cada
programador de esas aplicaciones mostrar todo correctamente, si lo muestra
mal ya es problema del programador de esas aplicaciones, o como controlar
uno esa *variedad enorme*.. El servidor es quien no debe devolver ninguna
informacion incorrecta.. Yo descargo de internet una lista de movimientos
en excel de mi cuenta bancaria, no soy libre de hacer lo que quiera con esos
datos para preparar un reporte? Claro que si. Si lo hago mal es problema mio
no del servidor ni del banco..
Si esas aplicaciones usan utilitarios para generar reportes que no sean
capaces de tomar un balance inicial y luego sumarle los debes y restarle los
haberes para calcular un balance final, pues deben buscarse otros
generadores de reportes o buscarse otros programadores mas capacitados.

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

Bueno si tienes pocos registros no es nada pero cuando hay muchos veras lo
que significaría estar recalculando constantemente en el servidor registro a
registro con los bloqueos que eso conlleva. Solo piensa en la concurrencia.
Digo del caso en que se hacen modificaciones o inserciones con fechas al
azar algo comun en los sistemas bancarios ya que las transacciones no llegan
siempre en el mismo orden de fechas ni los estados bancarios se dan en las
fechas calendarios.
Ademas no se como no te das cuenta que ese concepto es uno orientado a
registros, no a conjuntos.
Pero quien sabe tal vez tienes razon.
Si me muestras algun ERP que funcione asi te lo voy a creer.

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.

Deberias aterrizar en el tema particular de que estamos hablando ya que un
calculo de un saldo contable es el mismo creo que desde la antigua Grecia o
quizas antes.
Si lo generalizas a otros tipos de calculos o de cosas, pues te estas
alejando del tema particular y tal vez lo que hemos dicho aqui no tenga la
misma validez.

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é
epartamento (o aplicación) se le pregunte.

Ese seria un error grave administrativo del departamento de informatica de
ese banco pero no es culpa de su servidor de bases de datos.
Ahi es que entra lo de la capa de negocios.

Jose TH

necesario. Es cálculo no tiene por qué costar tanto;
saldo anterior + saldo del último movimiento, vaya cosa!
Si se hace en triggers, vistas materializadas o como sea
ya es otro problema.

No soy Jose Abreu :) pero parecido a lo que te dije en mi otro mensaje, el
ultimo movimiento o transaccion se basa en la fecha (digamos en la
fecha-hora) y estas fechas no necesariamente tienen porque introducirse en
orden en un sistema de cuenta corriente.
Ademas si haces un update de un valor de un registro del dias o meses atras,
que crees que tendrias que hacer? pues recalcular todos los registros de
fecha mayor que este para esa cuenta. Si es por trigger hasta tendrias que
evitar la recursividad de estos.
Y si le corriges la fecha a un registro, que tienes que hacer? pues habria
que tomar decision distinta si es mayor o menor que la que tenia. Mas
condiciones.
Y si le cambias la cuenta a un movimiento? pues tendrias que recalcular los
registros tanto para la anterior como para la nueva cuenta.
Y si eliminas un movimiento? y asi por el estilo, muchisimas reglas de
recalcular solo por evitar otros metodos de mas practicos y no perder una
discusion con razones mas teoricas que otra cosa...

Lo pones muy sencillo pero estoy seguro que no te has puesto a pensarlo.

Para mi esa opcion es la peor de todas de las que se han mencionado en el
hilo.


Saludos

Jose TH