Recalculo de saldo

1.- Esa tabla no está normalizada, la columna "saldo" es completamente
innecesaria y sólo se usa en la capa de presentación (Es una cuenta T de
Contabilidad).

Que no esta normalizada es cierto, pero no es cosa de la capa de
presentacion ya que se trata de una regla de negocios.

2.- El tener una columna saldo asume que nadie va a insertar un registro

con

una fecha anterior e invalidar todos los saldos posteriores.

No necesariamente, ya que ante una caida de sistema se puede operar en forma
manual y luego volcar los comprobantes una vez que todo vuelve a funcionar y
puede que se agreguen movimientos on line antes de que se vuelquen los
manuales,por citar un caso.
Tambien existe el caso de los movimientos a futuro, por lo que siempre
existe la posibilidad de que aparezca uno con fecha anterior al ultimo.

Se presentan problemas de integridad de información; si no, ¿por qué
necesitaría hacer un UPDATE como ese?

Eso es cierto pero es inherente a la realidad, ya que si se cae tu sistema y
operas "a mano", fallara la integridad de la informacion mas alla de la
normalizacion de tus tablas o de cualquier otra cosa

3.- Las soluciones para realizar semejante UPDATE no escalan

adecuadamente;

con tablas grandes, un cursor tal vez sea más apropiado que una solución

de

O(n^2) como la que le propuse.

El UPDATE no tiene porque actualizar toda la cuenta, sino desde el insert
hacia abajo, y no deberia haber gran problema con el rendimiento ya que la
gran mayoria de los insert son en el ultimo lugar.

Pero en fin, cada cabeza es un mundo, como decimos por acá.
¿Cuáles son tus razones para usar un diseño como ese?

Performance a la hora de las consultas

Leandro Sponton
Goya - Argentina

"LS - Sistemas" wrote in message
news:

> 1.- Esa tabla no está normalizada, la columna "saldo" es completamente
> innecesaria y sólo se usa en la capa de presentación (Es una cuenta T de
> Contabilidad).

Que no esta normalizada es cierto, pero no es cosa de la capa de
presentacion ya que se trata de una regla de negocios.

Ok. Si no es indiscreción, ¿cual es esa regla?

> 2.- El tener una columna saldo asume que nadie va a insertar un registro
con
> una fecha anterior e invalidar todos los saldos posteriores.

No necesariamente, ya que ante una caida de sistema se puede operar en

forma

manual y luego volcar los comprobantes una vez que todo vuelve a funcionar

y

puede que se agreguen movimientos on line antes de que se vuelquen los
manuales,por citar un caso.
Tambien existe el caso de los movimientos a futuro, por lo que siempre
existe la posibilidad de que aparezca uno con fecha anterior al ultimo.

Ya veo que necesitas este procedimiento para actualizar el saldo cuando los
datos se ingresan en desorden.

> Se presentan problemas de integridad de información; si no, ¿por qué
> necesitaría hacer un UPDATE como ese?

Eso es cierto pero es inherente a la realidad, ya que si se cae tu sistema

y

operas "a mano", fallara la integridad de la informacion mas alla de la
normalizacion de tus tablas o de cualquier otra cosa

Cierto. :)

> 3.- Las soluciones para realizar semejante UPDATE no escalan
adecuadamente;
> con tablas grandes, un cursor tal vez sea más apropiado que una solución
de
> O(n^2) como la que le propuse.

El UPDATE no tiene porque actualizar toda la cuenta, sino desde el insert
hacia abajo, y no deberia haber gran problema con el rendimiento ya que la
gran mayoria de los insert son en el ultimo lugar.

¡Perfecto! Mientras que el UPDATE no haga muchos renglones todo estará bien.

>
> Pero en fin, cada cabeza es un mundo, como decimos por acá.
> ¿Cuáles son tus razones para usar un diseño como ese?

Performance a la hora de las consultas

Leandro Sponton
Goya - Argentina

Maxi:

Estoy de acuerdo contigo en que hay que evitar cursoes como regla general,
pero también hay excepciones; los cursores tienen sus aplicaciones.

El cursor, en este caso, garantizaría que el orden sea O(n), mientras que la
solución que presenté es de O(n^2); mientras tengas tablas con pocos
registros no notarás la diferencia, pero cuando tengas cientos de miles o
millones sí que lo notarás. Además el cursor te permite particionar una
transacción gigantesca en partes (cuando no necesitas la atomicidad) para ir
avanzando en el proceso permitiendo a los demás usuarios consultar la
información, aunque la columna saldo será incorrecta, todo lo demás estará
bien.

También estoy de acuerdo en que las tablas no siempre deben estar
normalizadas; pero en las contabilidades que conozco, nunca he tenido
problemas con el concepto de saldo de una cuenta T. Y por lo general me da
mejores resultados el tomar el saldo del año/mes/dia anterior y sumar los
movimientos del período; guardar el saldo renglón por renglón me parece
demasiado. Pero cada aplicación tiene sus requerimientos propios y nada
sustituye a las pruebas para determinar si los cumples o no.

Saludos,
Eric Garza
AMIGE

"MAXI" wrote in message
news:%

Hola, nuevamente por aqui ;-)

No compoarto contigo que un cursor sea mejor!! todo lo contrario!! un

cursor

hara un recorrido entero de la tabla de una forma muy particular y si

ademas

este cursor esta dentro de una transaccion y es pesado el proceso, bueee

que

los demas usuarios por ese lapso se olviden de usar el sistema ;-)

Que no esta normalizada es verdad, pero quien dijo que todo debe estar
normalizado? hay ocaciones donde desnormalizar ayuda enormemente en
performance y hay sistemas que son muy criticos en este punto, por lo cual
quizas una desnormalizacion buena pueda ser interesante.

mmm, son formas nomas de hacer las cosas!! yo en todo caso siempre lo
pondria en un SP por muchas razones

(Seguridad, Performance, Reutilizacion, Sistematizacion para tus
desarrollarores)

Ademas mi concepto es otro, los motores de BDD lo que hacen muy bien es
trabajar justamente con datos, en el caso de Sql-Server hacen muy bien la
tera haciendo uso de T-sql dentro de SP por ej. Si no armas un SP estas
enviando los comandos por fuera, cosa que se recompilaran cada rato, estaras
teniendo acceso directo a las tablas (a menos que uses Roles de aplicacion,
pero claro no son 100% compatibles con otros motores y por ej en la version
7.0 no los tenes)


Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Eric Garza" escribió en el mensaje
news:%

Depende de muchos factores, el cálculo del saldo lo pondría en un

componente

en la capa de negocios o presentación.
Claro que si decides que el saldo sea una columna, como en este caso, el

SP

o un trigger son el mejor lugar para hacer la actualización del mismo.

Saludos,
Eric Garza
AMIGE

"MAXI" wrote in message
news:
> ERic, estoy totalmente de acuerdo contigo en lo que decis del diseño,

pero

> como has puesto que este tipo de operaciones no son para hacer en la

BDD,

me
> dio la sensacion de que hablas de armar una DLL y no usar SP.
>

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.781 / Virus Database: 527 - Release Date: 21/10/2004

Depende de muchos factores, el cálculo del saldo lo pondría en un componente
en la capa de negocios o presentación.
Claro que si decides que el saldo sea una columna, como en este caso, el SP
o un trigger son el mejor lugar para hacer la actualización del mismo.

Saludos,
Eric Garza
AMIGE

"MAXI" wrote in message
news:

ERic, estoy totalmente de acuerdo contigo en lo que decis del diseño, pero
como has puesto que este tipo de operaciones no son para hacer en la BDD,

me

dio la sensacion de que hablas de armar una DLL y no usar SP.