Columna Saldo de Cuenta Corriente

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

On Sat, 14 Jul 2007 09:14:22 -0400, "Ricardo Passians"
wrote:

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 la eficiencia es prácticamente la misma implementandolo de forma
procedimental en el servidor que en la aplicación.

A partir de un punto la eficiencia se vuelve menos importante que
otras variables. Sobrevalorar incrementos marginales en la velocidad
es un vicio que está muy extendido.

Implementarlo de forma procedimental ya es romper una regla, pero está
justificado por el mal funcionamiento de SQL Server con este tipo de
consultas.

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.

Y también podría traer calculados todos los saldos de forma que sea
muy sencillo presentarlos en el informe.


Saludos

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

On Sun, 15 Jul 2007 15:24:35 -0400, "principiante"
wrote:

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.

Absolutamente equivocado.

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.

Entonces forma parte del SGBD.

Y se dice acceder, no accesar.

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

Entonces tu "capa" cláramente forma parte del SGBD. Uno de los
problemas es que no entiendes bien lo que es un SGBD.

La cuestión es: ¿Que hace esa "capa" que no se pueda hacer más
fácilmente con SQL Server?

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.

Afirmación sin sentido.

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.

¿Haces trampas a propósito o sin querer?

¿No ves que lo que unas líneas más arriba era "concepto" lo has
cambiado por "método" cambiando completamente el sentido de la
afirmación?

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.

Tonterías. Muchos ERP, sobre todo los más tradicionales acumulan
montones de chapuzas y malas ideas de diseño que podrían horrorizar a
muchos expertos como Carlos.

Parece que no le has visto las "tripas" a muchos ERP.

Se aprende mucho de sus diseños aunque tu no lo creas, sabelotodo.

Se aprende mucho sobre lo que no se debe de hacer, y el insulto
sobraba.



Saludos

On Tue, 17 Jul 2007 12:35:42 +0200, Alfredo Novoa
wrote:

On Sat, 14 Jul 2007 09:14:22 -0400, "Ricardo Passians"
wrote:

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 la eficiencia es prácticamente la misma implementandolo de forma
procedimental en el servidor que en la aplicación.

A partir de un punto la eficiencia se vuelve menos importante que
otras variables. Sobrevalorar incrementos marginales en la velocidad
es un vicio que está muy extendido.

Implementarlo de forma procedimental ya es romper una regla, pero está
justificado por el mal funcionamiento de SQL Server con este tipo de
consultas.

Lo que quiero decir para que quede más claro, es que esa supuesta
diferencia de velocidad entre hacer una birria de suma en el cliente o
en el servidor no justifica el romper otra regla.


Saludos