Columna Saldo de Cuenta Corriente

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.

Es algo sorprendente escuchar a alguien decir que la experiencia no es
importante en esta o en cualquier profesion porque para mi si es fundamental
y muchas veces mas importante que la teoria. Si no te ayuda tu experiencia
debe ser porque no tienes mucha.

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.

No opino sobre eso porque ni me pasaria por la mente nunca ese tipo de
calculo "ad-hoc".

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.

A mi por supuesto que me importa, a ti lo que parece no importarte es la
experiencia como ya dijiste ni el performance de un sistema.

Entonces que evaluando solo lo
segundo lleguéis a las concusiones que llegáis no me parece
algo definitivo, ni mucho menos.

No te parece pero quizas cuando tengas mayor experiencia te pueda parecer.

Mira también mi reacción a Principiante.

Aprovecha tu tambien y lee sus ultimos mensajes no se porque me da la
impresion que lees muy rapido.

On 14 jul, 16:20, "principiante" wrote:

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

sum(bladibla) es una expresión que representa un cálculo, pero no
es un dato. 1234,00 es un saldo, un dato, pero no un cálculo.
Estamos ahora sincronizados?

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

Si es un dato. Según tu no lo es?
Y como tu lo explicas, entiendo que solo tiene significado en el
contexto de ese reporte.
Si es así, dos opciones:
- si los datos necesarios para el cálculo solo vienen al cliente
para hacer el cálculo entonces lo traería del servidor mediante
una consulta montada en el cliente y me ahorraría (al cliente,
a la red y al servidor) traer esos datos. En el servidor no hace
falta para eso programar aplicaciones ni cambiar nada.
- si los datos necesarios tienen que venir al cliente de todas
formas, lo haría en el reporte para no sobrecargar innecesariamente
el servidor. Aunque no está escrito en ningún sitio que una
máquina cliente no pueda tener una vida muy ajetreada.

Esto solo si es un dato que no tiene significado fuera del reporte.
Si sí tiene un significado fuera, entonces no solo lo traería del
servidor sino que la especificación de como calcularlo estaría
también en el servidor. En una vista, columna redundante calculada
en triggers, lo que a ti mas te guste o si prefieres, lo que mas
rabia te dé.

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?

He dicho yo que no podías hacer sumas y restas en reportes?
Estás atribuyendome cosas que no he dicho?

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, son datos.

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?

Estás implicando que el criterio por el cual se determina si hacer
algo en el reporte o en el SGBD es que si se puede hacer en el
reporte,
debe hacerse en el reporte?

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

Ahí va! New kid in town! :)
Y qué hace esta capa? Que responsabilidades tiene? Donde está esta
capa? No me refiero físicamente sino en cuanto a responsabilidades.
Responsabilidades a nivel de cliente, servidor, ...? Te estarás
refiriendo a 'reglas de negocio', supongo; qué son estas?
Y que significa que esté centralizada? Nadie puede acceder mas
al SGBD sin esa capa? O está detrás del SGBD?
Podrías aclarar todo esto?

Pero te puedes ahorrar la molestias. En la dichosa capa de negocios
se suelen implementar 'reglas de negocio'. Este es un término
informal que, en sistemas de información, viene a significar
restricciones de integridad y/o reglas de derivación de datos,
y esa es precisamente responsabilidad del SGBD.

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

Nadie. Estás de acuerdo con eso entonces?
Lo he dicho porque me parecía que el debate puede ser debido
a malentendidos en ese sentido, con todas sus consecuencias.
Y el que hayas sacado aquí arriba 'una capa de negocios' hace
que me sienta mas confidente en cuanto a ese presentimiento.

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

Bueno pues no los traemos todos. Calculamos medio saldo en el servidor
y la otra mitad en las aplicaciones. En cuanto a la determinación
de responsabilidades de subsistemas... vaya mejora.

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

Ya va mejor.
Pero.. por qué por mes? por qué no por año? semana? día? hora?
minuto?... Por qué no por transacción y con el saldo calculado
de una vez por todas? Por 'todas'... las veces que tendría
de otra forma que ser calculado y recalculado sabe Dios cuantas
veces y en cuantas aplicaciones y reportes.

>Y dónde?

Por supuesto que en el servidor.

Bien. Por qué hasta una fecha en el servidor y el resto en
las aplicaciones?

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

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

Ah! Tu me dices que lea lo de Ricardo. Te hago preguntas sobre el
asunto y me dices que relea a Ricardo!?
Además.. tu qué sabes donde yo he empezado a leer?

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

Pues hasta ahora he estado leyendo que en las aplicaciones,
reportes, la mitad aquí y el resto allá, ...

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

Totalmente de acuerdo. Y si una aplicación dice que el saldo es la
raíz cuadrada del saldo que le dá el servidor, es su problema.
'Mi punto' es que el servidor es el responsable de saber el saldo,
cualquier saldo, y saber darselo a quien le interese.
Lo que hagan las aplicaciones con el saldo, evidentemente es su
problema. Y?

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.

No se trata de lo que es capaz la aplicación, el sgbd o los
programadores, sino de lo que se debe hacer y dónde.
Hasta ahora estabamos hablando de un 'running' saldo por movimiento.
Tu ahora ya solo hablas de dos, de los cuales el primero lo
determina el servidor (saldo inicial) y el segundo el cliente (saldo
actual).

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

Hacer cálculos muy a menudo reportes y varias aplicaciones.. a eso
le llamo yo, quizás no constantemente, pero si recalcular lo ya
calculado mil veces. Y si te dá pena el pobre servidor y te
parece que los clientes tienen todo el tiempo del mundo, habrá que
comprar unos clientes mas baratos la próxima vez y el dinero que
sobra invertirlo en servidores más potentes. Pero las cosas hay
que hacerlas donde hay que hacerlas.

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.

Si eso tiene que ser posible entonces el saldo por movimieno no
tiene ningún sentido.
Una transacción tendrá una fecha a la que se refiere en el mundo
real pero también representa un transacción en el sistema, que
también tiene una fecha.
O cuando los contables apuntaban estas cosas ordenadamente en
sus libros cuando llegaba una factura 2 días demasiado tarde
metían un renglón en medio de los que ya tenían y corrían el resto
hacia abajo? Sería un poco estúpido eso. Y su saldo 'corriente'?
('running saldo?') lo calcularían, si lo hacían!?, según iban
escribiendo movimientos, digo yo!?. La serie de saldos escrita
estaba fija en el tiempo entonces.

Un consecuencia de modificar o borrar movimientos en vez de
introducir nuevos movimientos con correcciones o de no exigir que
estas tengan un orden total y fijo en el tiempo, sería:

24 enero 21:00 horas
Cliente a Servidor: Dame el saldo actual de la cuenta X
Servidor a Cliente: 234,00
25 enero 13:00 horas
Cliente a Servidor: Dame el saldo del 24 de enero a las 21:00 horas
de la cuenta X
Servidor a Cliente: -23,00

Puede alguien explicarme que valor informativo de este dato?

Pero en todo caso si hablamos de mi cuenta del banco tengo en
casa una carta que dice cual era mi saldo el 14 de febrero. Como
me vengan ahora con otro saldo para esa fecha me va a oír!
Aunque en ese saldo estubieran incluidas transacciones erroneas.
Estas tienen que corregirse con nuevas transacciones.
Por qué? Porque una transacción puede haberse comunicado a relaciones
fuera del sistema, como en mi carta, y cuando estos vuelvan pidiendo
explicaciones de esto o lo otro tendremos que tener en nuestro
sistema toda la información que se ha mandado al exterior.

Al telefono: Mire.. Me han mandado una carta y hay una transacción
que está mal y entonces tengo que tener otro saldo.
Respuesta(después de que alguien haya corregido la falta): pues aquí
está todo bien y como los ordenadores siempre tienen razón entonces
tiene usted que estar mintiendo. :o

Ademas no se como no te das cuenta que ese concepto es uno orientado a
registros, no a conjuntos.

Ni idea de qué concepto hablas.
Pero eres tu el que ha dicho "registro a registro" y no yo.

Pero quien sabe tal vez tienes razon.
Si me muestras algun ERP que funcione asi te lo voy a creer.

Aquí tampoco sé de que va. Ni veo cómo podría quitarme o darme la
razón (a mi o a ti), cualquiera de las posibles maneras en como
pueda funcionar un ERP. Totalmente irrelevante.

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

Yo no soy contable, ni griego, ni antiguo. Pero mira el ejemplo
arriba del saldo que es distinto dependiendo de cuando se le
pregunta al sistema. Cualquier contable griego te dirá que el SGBD
está respondiendo tonterías y desinformando en vez de informando.
Supongo claro, pero yo no soy contable (ni griego) y a lo mejor
tengo que aceptar que a los contables le gusta mirar reportes
repletos de tonterías y desinformación.

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

En eso estamos totalmente de acuerdo. El departamento de
informática no supo administrar que responsabilidades le
corresponden al SGBD y cuales a las aplicaciones.

Ahi es que entra lo de la capa de negocios.

Yeah right!
Seguro que en un mundo mágico de objetos.

Saludos,
Carlos

On 14 jul, 16:52, "principiante" wrote:

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

Si, ya sé. Tu eres 'otro' Jose :)

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.

Son datos históricos que no deberían cambiar, aunque tengan errores.
De otra forma daría lugar a sinsentidos. Mira también mi otra
reacción.

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.

La fecha de la transacción en el sistema es el timestamp del momento
de entrada del registro y no otra. Que, por cierto, esto todavía no
es suficiente para forzar un orden total, que es necesario para
tener un 'running' saldo estable. El saldo antes de esa transacción
era uno y después otro. Ese no cambia más. Si alguna transación
tiene un fallo, pues se introduce otra transación de corrección.
Y el error queda registrado también como dato histórico. Infomación
con ese error puede haber salido del sistema y cuando, por ejemplo,
el cliente, otro departamento, llame por teléfono pidiendo
explicaciones, debe haber un historial para poder dárselas.
(Mira mi otra reacción)

Si esto no es así, el 'running' saldo me parece un sinsentido, que
no tiene ningún valor informativo; independientemente de donde se
calcule. El sistema no debe pretender que ayer sabía lo que sabe
hoy. Ni debe pretender que una transacción ha entrado ayer, si ha
entrado hoy.

Y si le cambias la cuenta a un movimiento? pues tendrias que recalcular los
registros tanto para la anterior como para la nueva cuenta.

A un movimiento no se debería cambiarle la cuenta.
Lo mismo que arriba.

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

Un movimiento no debería eliminarse. Solo cuando se cierra un
período, determinando así un nuevo saldo inicial para el período
siguiente.
Aunque si lo haces véase arriba.

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

Lo que tu digas! Pero yo pienso que tu lo pones innecesariamente
muy complejo. De esa forma el 'running' saldo es un sinsentido.

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

Entre tanto texto ya ni sé de que opción hablas.

Saludos,
Carlos

On 15 jul, 02:12, "Jose Abreu" wrote:

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

Es algo sorprendente escuchar a alguien decir que la experiencia no es
importante en esta o en cualquier profesion

Dónde he dicho yo que no es importante?

porque para mi si es fundamental
y muchas veces mas importante que la teoria.

Pues.. en el contexto de nuestra profesión, debes tener un concepto
muy raro de 'fundamental'.

Si no te ayuda tu experiencia
debe ser porque no tienes mucha.

Y dale! He dicho yo que no me ayuda mi experiencia?
Y qué sabrás tu si es mucha o poca?!

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

No opino sobre eso porque ni me pasaria por la mente nunca ese tipo de
calculo "ad-hoc".

El saldo actual después de introducir un nuevo movimento, en orden
de introducción en el sistema, es el saldo anterior + el saldo del
moviminto que se introduce. Qué tiene eso de ad hoc?

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

A mi por supuesto que me importa, a ti lo que parece no importarte es la
experiencia como ya dijiste ni el performance de un sistema.

Dónde dije yo eso?
Estoy empezando a dudar si sabes leer porque no dejas de atribuirme
cosas que no he escrito.

>Entonces que evaluando solo lo
>segundo lleguéis a las concusiones que llegáis no me parece
>algo definitivo, ni mucho menos.

No te parece pero quizas cuando tengas mayor experiencia te pueda parecer.

Pero es, entre otras cosas, mi experiencia lo que me lleva a decir
eso. Y se confirma casi a diario.
Pero... a ver... habrá que esperar mas entonces :)

>Mira también mi reacción a Principiante.

Aprovecha tu tambien y lee sus ultimos mensajes no se porque me da la
impresion que lees muy rapido.

Si si, ya los he leído. Te refieres a algo en particular?

Saludos,
Carlos

Hey, a usted se ve que le encanta escribir!!!!

> Es tu opinion.

>El saldo es un dato.

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


sum(bladibla) es una expresión que representa un cálculo, pero no
es un dato. 1234,00 es un saldo, un dato, pero no un cálculo.
Estamos ahora sincronizados?

Absolutamente no.

>aplicación, ad hoc sql, etc.) se pida.

Y como tu lo explicas, entiendo que solo tiene significado en el
contexto de ese reporte.
Si es así, dos opciones:
- si los datos necesarios para el cálculo solo vienen al cliente
para hacer el cálculo entonces lo traería del servidor mediante
una consulta montada en el cliente y me ahorraría (al cliente,
a la red y al servidor) traer esos datos.


En el servidor no hace
falta para eso programar aplicaciones ni cambiar nada.
- si los datos necesarios tienen que venir al cliente de todas
formas, lo haría en el reporte para no sobrecargar innecesariamente
el servidor. Aunque no está escrito en ningún sitio que una
máquina cliente no pueda tener una vida muy ajetreada.

Bueno, me das la razon pero eso de cliente muy ajetreado es relativo sino
para que existirian los namespaces de datos, los generadores de reportes en
los lenguajes de programacion del lado de los clientes.

Esto solo si es un dato que no tiene significado fuera del reporte.
Si sí tiene un significado fuera, entonces no solo lo traería del
servidor sino que la especificación de como calcularlo estaría
también en el servidor. En una vista, columna redundante calculada
en triggers, lo que a ti mas te guste o si prefieres, lo que mas
rabia te dé.

O un procedimiento almacenado de la CAPA de NEGOCIOS.

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?

He dicho yo que no podías hacer sumas y restas en reportes?

Una cosa es no decirlo explicitamente y otra es dejarlo por sentado
implicitamente sugiriendo que es una catastrofe calcular un saldo en un
reporte.

Estás atribuyendome cosas que no he dicho?

Leete tu mismo y otros mensajes de otros y veras que no solo a mi me ha
estado pasando. Por que sera?
Revisar la forma de redaccion quizas.

por dia para el verlo de esa forma aparte de detallado. Estos totales
tambien son datos, no es asi?

Si, son datos.
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?


Estás implicando que el criterio por el cual se determina si hacer
algo en el reporte o en el SGBD es que si se puede hacer en el
reporte, debe hacerse en el reporte?

Tienes un problema como de generalizar las cosas saliendote del tema
particular.
Esa pregunta si que es irrelevante.

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


Ahí va! New kid in town! :)
Y qué hace esta capa? Que responsabilidades tiene?

Permite, si es necesario, hacer que todos los programadores trabajen de
manera homogenea con los datos elementales y derivados de la BD.

Donde está esta
capa? No me refiero físicamente sino en cuanto a responsabilidades.

No se de otros pero para mi es un conjunto de vistas, procedimientos y
funciones que pueden estar en el mismo servidor de bases de datos o hasta en
otro servidor de bases de datos intermedio, dependiendo de que tan grande
sea la estructura.

Responsabilidades a nivel de cliente, servidor, ...? Te estarás
refiriendo a 'reglas de negocio', supongo; qué son estas?

Yo le llame capa de negocios, algo mas generico quizas no exactamente reglas
que es algo mas especifico.

Y que significa que esté centralizada? Nadie puede acceder mas
al SGBD sin esa capa? O está detrás del SGBD?
Podrías aclarar todo esto?

Centralizada es que fuerza a los programadores a accesar la base de datos a
traves de ella, por tanto puedo hacer verbigracia que nadie me lea
directamente la tabla de transaciones sino a traves de una vista o una
funcion o un procedimiento almacenado.
No lo veas como algo fisico sino un concepto.

Pero te puedes ahorrar la molestias. En la dichosa capa de negocios
se suelen implementar 'reglas de negocio'. Este es un término
informal que, en sistemas de información, viene a significar
restricciones de integridad y/o reglas de derivación de datos,
y esa es precisamente responsabilidad del SGBD.

Y quien dice que esa capa no resida en el mismo servidor?. Creo que tu
problema en esta discusion viene de que minimizas los conocimientos de los
demas. Se que soy el principiante pero no es para tanto:)
Se que responderas luego que no, pero eso es lo que dejas demostrar.

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

Nadie. Estás de acuerdo con eso entonces?
Lo he dicho porque me parecía que el debate puede ser debido
a malentendidos en ese sentido, con todas sus consecuencias.
Y el que hayas sacado aquí arriba 'una capa de negocios' hace
que me sienta mas confidente en cuanto a ese presentimiento.

Algun problema de sabelotodismo tienes.

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?

ueno pues no los traemos todos. Calculamos medio saldo en el servidor
la otra mitad en las aplicaciones. En cuanto a la determinación
e responsabilidades de subsistemas... vaya mejora.

ya acumulados y solo agregarle los movimientos del mes de la fecha
indicado.. Que te parece?

Ya va mejor.
Pero.. por qué por mes? por qué no por año? semana? día? hora?
minuto?...

No estas comprendiendo bien la idea.

>Y dónde?

Por supuesto que en el servidor.

Bien. Por qué hasta una fecha en el servidor y el resto en
las aplicaciones?

Por que es mas eficiente y no es algo tan grave para el ejemplo particular,
exclusivo, especifico, aislado, etc.etc.etc,... de que estamos hablando.
Tampoco estamos hablando de algo generico que deba ser asi siempre como tu
tratas de adjudicar a mi planteamiento.
Te lo he dicho antes pero insistes en no enterarte de nada. La verdad que
da trabajo discutir en ese plano.

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

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

Ah! Tu me dices que lea lo de Ricardo. Te hago preguntas sobre el
asunto y me dices que relea a Ricardo!?

Por que crees? pues porque alli el lo explica claro lo mismo que tu estas
preguntando como haciendote el desentendido.

Además.. tu qué sabes donde yo he empezado a leer?

Y tu que sabes si uno esta entendiendo o no todas las cosas que tu escribes?
Piensas que se entiende claro todo lo que escribes??? deberias revisarte.

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



Pues hasta ahora he estado leyendo que en las aplicaciones,
reportes, la mitad aquí y el resto allá, ...

Claro y seguro lo estamos generalizando para todo? Estrategia ligera.

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

Totalmente de acuerdo. Y si una aplicación dice que el saldo es la
raíz cuadrada del saldo que le dá el servidor, es su problema.

Claro para gente que no sabe ni un apice de programacion ni de un generador
de reportes.

'Mi punto' es que el servidor es el responsable de saber el saldo,
cualquier saldo, y saber darselo a quien le interese.
Lo que hagan las aplicaciones con el saldo, evidentemente es su
problema. Y?

Y? pues que te desvias del tema que estamos hablando pretendiendo que
estamos hablando de algo general.
Debe ser la decima vez que te lo digo.

generadores de reportes o buscarse otros programadores mas capacitados.



No se trata de lo que es capaz la aplicación, el sgbd o los
programadores, sino de lo que se debe hacer y dónde.
Hasta ahora estabamos hablando de un 'running' saldo por movimiento.
Tu ahora ya solo hablas de dos, de los cuales el primero lo
determina el servidor (saldo inicial) y el segundo el cliente (saldo
actual).

Yo siempre sigo hablando de un "running" saldo. Lo que pasa que el ultimo
coincidira con el saldo actual. Es lo mismo pero veo que a ti hay que darte
demasiados detalles y la verdad ya cansa.

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.


Hacer cálculos muy a menudo reportes y varias aplicaciones.. a eso
le llamo yo, quizás no constantemente, pero si recalcular lo ya
calculado mil veces. Y si te dá pena el pobre servidor

Claro me da pena... por que es uno solo.
Dejas ver desconocimiento sobre tips de rendimiento en el servidor.

y te
parece que los clientes tienen todo el tiempo del mundo, habrá que
comprar unos clientes mas baratos la próxima vez y el dinero que
sobra invertirlo en servidores más potentes. Pero las cosas hay
que hacerlas donde hay que hacerlas.

Eso no pasa de la teoria por que hay que tratar de seguirla siempre pero las
limitaciones de la tecnologia hacen que no siempre se deba hacer las cosas
de forma tan religiosa, para obtener mejores resultados.
Eso seria parecido a decir que siempre y religiosamente hagamos
normalizacion hasta la maxima forma normal o que utilicemos cursores de
servidor porque es preferible a tener que recorrer un cursor en la
aplicacion.
No dudo que en otra discusion digas exactamente lo contrario, ya me vas
dando que eres de ese tipo.

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.

Si eso tiene que ser posible entonces el saldo por movimieno no
tiene ningún sentido.

Por supuesto que no lo tiene, debiste darte cuenta mucho antes de plantear
esa idea tan descabellada.

Una transacción tendrá una fecha a la que se refiere en el mundo
real pero también representa un transacción en el sistema, que
también tiene una fecha.

Deberias leer algo sobre temas contables... ufff.

O cuando los contables apuntaban estas cosas ordenadamente en
sus libros cuando llegaba una factura 2 días demasiado tarde
metían un renglón en medio de los que ya tenían y corrían el resto
hacia abajo? Sería un poco estúpido eso.

Pues es exactamente asi como se hace en muchos (quizas la mayoria) de los
sistemas contables.

introducir nuevos movimientos con correcciones o de no exigir que
estas tengan un orden total y fijo en el tiempo, sería:

24 enero 21:00 horas
Cliente a Servidor: Dame el saldo actual de la cuenta X
Servidor a Cliente: 234,00
25 enero 13:00 horas
Cliente a Servidor: Dame el saldo del 24 de enero a las 21:00 horas
de la cuenta X
Servidor a Cliente: -23,00

Puede alguien explicarme que valor informativo de este dato?

Precisamente por eso es un sinsentido tratar de hacer lo que propusiste.

Pero en todo caso si hablamos de mi cuenta del banco tengo en
casa una carta que dice cual era mi saldo el 14 de febrero. Como
me vengan ahora con otro saldo para esa fecha me va a oír!
Aunque en ese saldo estubieran incluidas transacciones erroneas.
Estas tienen que corregirse con nuevas transacciones.
Por qué? Porque una transacción puede haberse comunicado a relaciones
fuera del sistema, como en mi carta, y cuando estos vuelvan pidiendo
xplicaciones de esto o lo otro tendremos que tener en nuestro
istema toda la información que se ha mandado al exterior.

Eso es en un mundo ideal y hasta podria ser en los bancos donde hay mucho
control en el sistema bancario desde el punto de vista de ellos, pero no en
el de nosotros para conciliar la cuenta corriente. En los sistemas
contables normales que nosotros instalamos nos piden que mientras no se haya
cerrado un mes, y a veces hasta un año, se puedan modificar los registros
libremente.
Y en el caso que si pueda que con la cuenta del banco no sea necesario, te
lo exigen que sí lo sea con las demas cuentas contables. No contemplar eso
es hacer un sistema muy rigido.

Ademas no se como no te das cuenta que ese concepto es uno orientado a
registros, no a conjuntos.
Ni idea de qué concepto hablas.
ero eres tu el que ha dicho "registro a registro" y no yo.

Estaré hablando con alguien con doble personalidad? Pero quien es que ha
hablado de ese metodo de al ultimo movimiento le sumo el nuevo ? de
"running" balance? eso no es orientado a registros?
Parece que estamos hablando idiomas diferentes.

ro quien sabe tal vez tienes razon.
Si me muestras algun ERP que funcione asi te lo voy a creer.


Aquí tampoco sé de que va. Ni veo cómo podría quitarme o darme la
razón (a mi o a ti), cualquiera de las posibles maneras en como
pueda funcionar un ERP. Totalmente irrelevante.

Te defiendes muy mal porque muchos ERP sobre todo los mas tradicionales
aunque no sean infalibles acumulan la experiencia y las ideas de diseño
eficientes para sistemas contables que muchos principiantes como yo o como
tu no so­ñamos con alcanzar.
Se aprende mucho de sus diseños aunque tu no lo creas, sabelotodo.

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.

Yo no soy contable, ni griego, ni antiguo.

Lo primero y lo segundo se nota a leguas :)

Ese seria un error grave administrativo del departamento de informatica de
ese banco pero no es culpa de su servidor de bases de datos.

En eso estamos totalmente de acuerdo. El departamento de
informática no supo administrar que responsabilidades le
corresponden al SGBD y cuales a las aplicaciones.

Ahi es que entra lo de la capa de negocios.

Yeah right!
Seguro que en un mundo mágico de objetos.

Ya te explique arriba lo que es para mi una capa de negocios, lo que sea
para ti no se y la verdad que no me interesa. Dejemoslo ahi no!, haz tu
running balance como quieras!!!
uff... con tal de no volver a leer un mensaje tan largo :)