Columna Saldo de Cuenta Corriente

06/07/2007 - 21:18 por msnews.microsoft.com | Informe spam
Hota a todos, una consulta,

en una query que trae datos de una cuenta corriente, (campos de la tabla:
Fecha, Concepto, Debe y Haber), es posible agregar una columna que vaya
calculando el Saldo resultante ?

Saludos y muchas gracias de antemano

Pablo

Preguntas similare

Leer las respuestas

#41 Jose Abreu
17/07/2007 - 14:34 | Informe spam
Lo dicho no seras el marido de Carlos?


"Alfredo Novoa" escribió en el mensaje
news:
On Fri, 13 Jul 2007 16:37:04 -0400, "principiante"
wrote:

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.



Eso no es un problema, el problema es que no tiene sentido tener
almacenados datos redundantes para un cálculo tan rápido de hacer.


Saludos
Respuesta Responder a este mensaje
#42 Jose Abreu
17/07/2007 - 14:37 | Informe spam
joer... cuantas burradas has dicho amigo.
De verdad tu trabajas en sistemas o eres abogado en una oficina publica?

Lo dicho no seras el marido de Carlos?



"Alfredo Novoa" escribió en el mensaje
news:
On Sat, 14 Jul 2007 10:20:33 -0400, "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.



Desde luego que vas mal. El saldo es un dato y no entender eso es no
entender nada.

Siempre viene bien consultar el diccionario, sobre todo ahora que se
puede hacer de forma tan cómoda por Internet

Dato.
3. m. Inform. Información dispuesta de manera adecuada para su
tratamiento por un ordenador.

Queda claro que no hay discusión posible.

Segun tu, un total de ventas de un reporte, solo para poner otro ejemplo,
también es un dato



Por supuestísimo.

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?



No entiendes nada.

O respondeme entonces que es lo que tu haces en los generadores de
reportes
que tienen valores?



Esta frase no tiene sentido.

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?



Evidentemente.

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?



Si el servidor te hace eso. ¿Por que vas a cargar la aplicación con
ese cálculo que te hace el servidor?

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



¿Y que tiene que ver donde se diseñan los informes con donde se
realizan los cálculos?

Deberías de pensar un poco más en lo que escribes.

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.



Lo estás discutiendo tú. Parece que no entiendes bien lo que lees.

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



Aquí queda mucho más claro que no entiendes el español escrito.

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



Esto está bien, pero de lo que estás hablando es de calcular datos en
las aplicaciones y no solamente de mostrarlos.

Si los datos que vienen del servidor son correctos y los programas no
tienen que hacer ningún cálculo, entonces es bastante difícil mostrar
mal los datos. Creo que ese es el punto de vista de Carlos.

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



Tuyo y de tu jefe y de tu empresa y de tus clientes, por eso es mejor
reducir las posibilidades de que lo hagas mal, y eso se puede hacer
centralizando los cálculos en el servidor.

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.



¿Que razón habría para hacer esto si los saldos te llegasen
calculados?

Tus razonamientos no van a ninguna parte.

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



Esto es un disparate.

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



¿Y que tiene que ver que haya algún ERP que funcione así (que seguro
que los hay), con tener razó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.
Ahi es que entra lo de la capa de negocios.



¿Te refieres a crearte tu propio SGBD de propósito específico con un
lenguaje procedimental para hacer los mismo que se puede hacer con SQL
Server de forma inmediata?



Saludos
Respuesta Responder a este mensaje
#43 Jose Abreu
17/07/2007 - 14:40 | Informe spam

Hasta ahi no es un sinsentido, ni yo lo he satanizado en principio, es
solo
una consulta que algunos pensamos que podria ser muy lenta cuando hay
muchos
registos, salvo ver los planes de ejecucion como dije en otro mensaje.


Es lenta y no es la culpa de la consulta, sino del optimizador, que no
se entera.




Tremenda deduccion, amigo..!!! y luego luego los que no sabemos leer ni
entender somos otros..

ya veo porque la experiencia yo es nada fundamental en informatica..

ya vere a tu marido defendiendote.
Respuesta Responder a este mensaje
#44 Juan Diego Bueno
17/07/2007 - 14:41 | Informe spam
"Jose Abreu" escribió en el mensaje
news:


no es por risa sino por verguenza que te dan dolores de estomago!


A mí lo que me da vergüenza, pero ajena es leer un comentario del tipo "Y
tu, seras el marido de Carlos ?" totalmente fuera de lugar.

¿Es que no sabéis debatir sin recurrir a descalificaciones? ¿Es ese el único
razonamiento para defender vuestros argumentos?

En fín...
Respuesta Responder a este mensaje
#45 Alfredo Novoa
17/07/2007 - 14:47 | Informe spam
On Tue, 17 Jul 2007 08:34:29 -0400, "Jose Abreu" wrote:

Lo dicho no seras el marido de Carlos?



¡Pero si acabo de criticar su propuesta, pedazo de imbécil!

Te meto en el filtro anti-idiotas.
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida