Columna Saldo de Cuenta Corriente
msnews.microsoft.com
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
Ricardo Passians
registro; eso sería sobrecargar el servidor innecesariamente además de
complicarse la vida.
Solo basta con sacar el balance inicial a la fecha anterior (al rango de
fechas indicado) y devolverlo a la aplicación junto al conjunto de datos.
En la aplicación le pasas eso a un formulario o a un reporte que por suma
simple te vaya mostrando el saldo resultante registro por registro.
Saludos,
Ricardo Passians
"msnews.microsoft.com" <mauriz...@flair.com.ar> escribió en el mensaje
news:%23LfMpJA...@TK2MSFTNGP05.phx.gbl...
msnews.microsoft.com
que decís lo sé hacer, pero lo que quisiera saber si se puede hacer traer la
columna directamente con la query, no pasarlo a un formulario y que el VB
(por ej.) vaya calculando el saldo. Precisamente eso es lo que quiero
evitar.
Quiero poner la consulta en un SP, e invocarla desde Excel, o desde VB, por
ej. y que ya vengan las 3 columnas (Debe, Haber y "Saldo"), generadas por el
SQL
Las columnas Debe y Haber son campos de una tabla, pero Saldo debería
calcularla SQL
se entiende la consulta?
si no por favor decime así trato de ampliarla
saludos y muchas gracias de antemano
Pablo
"Ricardo Passians" <ricardit...@hotmail.coSm> escribió en el mensaje
news:%23qUaURA...@TK2MSFTNGP02.phx.gbl...
Ricardo Passians
> que decís lo sé hacer, pero lo que quisiera saber si se puede hacer traer
> la columna directamente con la query, no pasarlo a un formulario y que el
> VB (por ej.) vaya calculando el saldo. Precisamente eso es lo que quiero
> evitar.
Yo entiendo lo que escribiste solo te estoy diciendo que no veo la necesidad
de sobrecargar al servidor con eso puesto que en cualquier aplicación, sea
Excel, VB o fortran puedes presentarlo como quieras, teniendo solo el
balance inicial y el conjunto.
Pero... ya que insistes en trabajar con registros en un servidor orientado
a set's, una forma (hay más) de hacerlo en un SP es con una tablita
temporal.
Ej: (es solo una idea para que lo implementes en tu SP a tu manera):
--parametros son @CUENTA, @FECHA1 y @FECHA2, la tabla de movimientos es MOV
DECLARE @BALANCEINICIAL NUMERIC(14,2)
--calculo el balance inicial
SET @BALANCEINICIAL=(SELECT ISNULL(SUM(DEBE-HABER),0) FROM MOV
WHERE CUENTA=@CUENTA AND FECHA<@FECHA1)
--meto el rango de movimientos a una tabla temporal #tmpMOV,
--añadiendo una columna virtual SALDO en cero
SELECT
FECHA, CONCEPTO, DEBE, HABER, SALDO=CAST(0 AS NUMERIC(14,2))
INTO #tmpMOV /*tabla temporal*/
FROM MOV
WHERE CUENTA=@CUENTA AND FECHA>=@FECHA1 AND FECHA<@FECHA2+1
ORDER BY FECHA
--actualizo el campo virtual SALDO, reacumulando en la variable
@BALANCEINICIAL
--aquí es que está realmente la solución
UPDATE #TMPMOV
SET @BALANCEINICIAL=SALDO=@BALANCEINICIAL+DEBE-HABER
--devuelvo el conjunto
SELECT * FROM #TMPMOV
Ojalá te sirva.
Saludos
Ricardo Passians
Rafael
> que decís lo sé hacer, pero lo que quisiera saber si se puede hacer traer
> la columna directamente con la query, no pasarlo a un formulario y que el
> VB (por ej.) vaya calculando el saldo. Precisamente eso es lo que quiero
> evitar.
>
> Quiero poner la consulta en un SP, e invocarla desde Excel, o desde VB,
> por ej. y que ya vengan las 3 columnas (Debe, Haber y "Saldo"), generadas
> por el SQL
> Las columnas Debe y Haber son campos de una tabla, pero Saldo debería
> calcularla SQL
>
Yo pienso igual que Ricardo, lo que deberias evitar es hacer esas cosas en
un query del servidor.Cualquier solucion para eso tiene un costo alto en el
servidor.
En Excel no te lleva ni dos minutos agregar una columna saldo, en Crystal
reports por igual, en un formulario tambien.
Si se tratara de otro dato agregado tal vez se justifique pero ese caso
pienso que es mas eficiente hacerlo en el front -end.
Rafael
> reports por igual, en un formulario tambien.
Cuando digo dos minutos hablo de poner la formula o definirla no a la
ejecucion, que ni se notará.
Carlos M. Calvelo
On 6 jul, 21:18, "msnews.microsoft.com" <maurizi.pa...@flair.com.ar>
wrote:
> 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 ?
>
Añado un campo 'num' porque puede haber varios registros con la
misma fecha.
Asumiendo que:
- la combinación (fecha,num) es única
- que la tabla solo tiene una cuenta
- debe y haber no pueden tener nulos
select a.fecha, a.num, a.concepto, sum(b.debe - b.haber) as saldo
from cuenta a inner join cuenta b
on a.fecha > b.fecha or (a.fecha = b.fecha and a.id >= b.id)
group by a.fecha, a.num, a.concepto
Saludos,
Carlos
Carlos M. Calvelo
> select a.fecha, a.num, a.concepto, sum(b.debe - b.haber) as saldo
> from cuenta a inner join cuenta b
> on a.fecha > b.fecha or (a.fecha = b.fecha and a.id >= b.id)
> group by a.fecha, a.num, a.concepto
>
corrección:
select a.fecha, a.num, a.concepto, sum(b.debe - b.haber) as saldo
from cuenta a inner join cuenta b
on a.fecha > b.fecha or (a.fecha = b.fecha and a.num >= b.num)
group by a.fecha, a.num, a.concepto
order by a.fecha,a.num
saludos
Isaias
solucion, que espero puedas aplicarlo en tu query:
----------------------------------------------------------------------------------------------
soy un poco novato con esto de las Select, y tengo una duda. La duda es la
siguiente.
Tengo una tabla, en la cual almaceno los datos sobre los movimientos de una
cuenta bancaria con los siguientes campos.
Id_Movimiento
Id_Cuenta
Fecha
Tipo -- campo que indetifica si es un ingreso o un pago
Cantidad
concepto
Quisiera saber como puedo sacar una select con todos los campos y ademas el
saldo por cada movimineto?
-- DR Alejandro Mesa
select
Id_Movimiento,
Id_Cuenta,
Fecha,
Tipo,
concepto,
cantidad,
(
select sum(case when tipo = 'I' then cantidad else (-1 * cantidad) end)
from dbo.movimientos as m2
where
m2.cuenta = m1.cuenta
and
(
m2.fecha < m1.fecha
or (m2.fecha = m1.fecha and m2.Id_Movimiento <= m1.Id_Movimiento)
)
)as saldo
from
dbo.movimientos as m1
order by
Id_Cuenta,
Fecha
go
--
Saludos
IIslas
msnews.microsoft.com
voy a analizarlas para ver que opción tomar
la opción de presentarlo directamente en el Front-End es la que vengo usando
hace mucho tiempo, solo quería ver si había algo mejor
de nuevo, muchas gracias, son muy generosos
Saludos
Pablo
"Isaias" <Isa...@discussions.microsoft.com> escribió en el mensaje
news:8A93CDB2-6000-4001...@microsoft.com...
principiante
> voy a analizarlas para ver que opción tomar
> la opción de presentarlo directamente en el Front-End es la que vengo
> usando hace mucho tiempo, solo quería ver si había algo mejor
>
La mejor manera es revisar los planes de ejecucion de las opciones que te
han dado para ver si realmente se justifica no hacerlo en el Front-End, como
parece ser lo mas adecuado aqui por lo costosa que pueden ser esas consultas
que envuelven subconsultas.
Jose TH
Carlos M. Calvelo
El hacerlo y no el 'no hacerlo' en el front-end necesita
justificación.
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.
Otra alternativa sería calcular el saldo cuando se actualizan los
registros y no al consultar.
Saludos,
Carlos
principiante
>El hacerlo y no el 'no hacerlo' en el front-end necesita
>justificación.
>
Es tu opinion.
Yo creo que es lo contrario.
>
>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. 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).
>
>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.
Saludos
Jose TH
Ricardo Passians
> 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)
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.
>>
>>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.
Podría evaluarse quizás pero también creo que los triggers deberían evitarse
siempre que haya mejores opciones debido, entre otras importantes razones de
mantenimiento, a que ralentizan las actualizaciones.
No creo por tanto que esa opción sea conveniente tampoco en este caso.
Saludos
Ricardo Passians
Jose Abreu
> 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.
>
>>>
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.
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.
Bye
José Abreu
Carlos M. Calvelo
> >El hacerlo y no el 'no hacerlo' en el front-end necesita
> >justificación.
>
> Es tu opinion.
El saldo es un dato. 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.
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.
Una opinión fundamentada entonces... y no solo mía.
> Yo creo que es lo contrario.
Ya veo! :)
>
>
>
> >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?
> 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).
Cómo se calcula 'el balance inicial' para la primera fecha del rango
que se pide? (que puede ser cualquier fecha) Y dónde?
Cómo se calcula el saldo actual para un lista de cuentas? (por
ejemplo: no_cuenta, nombre, fecha_última_transación, saldo) 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?
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.
>
>
>
> >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.
Además que eso no tiene por qué ser así. Si estamos hablando de
algo serio, esos son datos históricos. Y si ha habido algún fallo,
como hecho histórico tiene que quedar registrado, por ejemplo
porque ya ha sido comunicado al exterior, a clientes.
Se introduce entonces un nuevo movimiento representando una
corrección, que es otro hecho histórico.
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.
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é
departamento (o aplicación) se le pregunte.
Saludos,
Carlos
Carlos M. Calvelo
>
> 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
Carlos M. Calvelo
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
Ricardo Passians
>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
principiante
> >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
principiante
>
>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
Jose Abreu
>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.
Carlos M. Calvelo
> > >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
Carlos M. Calvelo
> >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
Carlos M. Calvelo
> >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
principiante
> > 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 :)
Carlos M. Calvelo
On Sun, 15 Jul 2007 15:24:35 -0400, principiante wrote:
>
>>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.
De contabilidad ni idea! Ni me interesa. Pero yo he trabajado en
dos sistemas de contabilidad que para cada movimiento tenían una
fecha de introducción en el sistema y otra de referencia a la
transación. Estos movimientos no se podían cambiar y errores solo
podían corregirse con nuevos movimientos.
>
>>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.
Vamos, que sí son estúpidos estos sistemas.
>
>>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.
Mi primera reacción en este hilo:
-----------------------------------------------------------------
Añado un campo 'num' porque puede haber varios registros con la
misma fecha.
Asumiendo que:
- la combinación (fecha,num) es única
- que la tabla solo tiene una cuenta
- debe y haber no pueden tener nulos
select a.fecha, a.num, a.concepto, sum(b.debe - b.haber) as saldo
from cuenta a inner join cuenta b
on a.fecha > b.fecha or (a.fecha = b.fecha and a.id >=
b.id)
group by a.fecha, a.num, a.concepto
-------------------------------------------------------------------
(al final lo de 'id' fue una equivocación y tiene que ser 'num')
Por qué crees que he introducido el num? Para forzar un orden total
y darle sentido al running saldo. Y todo el tiempo asumiendo que la
fecha es un timestamp del sistema y que lo que se ha introducido es
definitivo.
Después vienes tu y hablas de actualizar fechas, borrar movimientos,
etc, etc.
Entonces doy aquí un ejemplo de que si eso puede ser, el running
saldo va a ser un sinsentido. Lo calcule el sgbd, el reporte, la
aplicación o mi abuela.
Y tu conclusión ahora es que lo que yo propongo es un sinsentido!
Venga ya hombre... vete a tomar el fresco, que te hace falta.
Concluir, desconfiar que hay confusión es una cosa, pero otra muy
distinta es que lo que yo propongo es lo que sí es un sinsentido.
Eso aparte de que: sql reporting también sabe sumar, que si el ERP
enseña mucho a principantes con tu y yo, que si sabelotodismo,
sabelotodo, ..., etc, etc, etc.
Por cierto... son muchas las cosas de las que no tengo ni idea,
pero principiante lo serás tu!
Lo dicho.... a tomar el fresco.
principiante
news:1184536564.2...@g4g2000hsf.googlegroups.com...
>
>De contabilidad ni idea! Ni me interesa. Pero yo he trabajado en
>dos sistemas de contabilidad que para cada movimiento tenían una
>fecha de introducción en el sistema y otra de referencia a la
>transación.
>Estos movimientos no se podían cambiar y errores solo
>podían corregirse con nuevos movimientos.
>
Hay sistemas que son asi pero son muy rigidos por ejemplo para pymes.
>
>>
>
> Pues es exactamente asi como se hace en muchos (quizas la mayoria) de los
> sistemas contables.
>
>Vamos, que sí son estúpidos estos sistemas.
>
No lo creo.
Eso se da igual con las existencias y los costos en sistemas de control de
existencias de almacen y en general en cualquier sistema donde hay que
mantener saldos y movimientos de altas y bajas.
Ponte a pensarlo.
Yo creo que lo estúpido es no entender las necesidades de los usuarios, pero
el termino no va a los sistemas sino a los analistas.
>
>>
>
> Precisamente por eso es un sinsentido tratar de hacer lo que propusiste.
>
>Mi primera reacción en este hilo:
>-----------------------------------------------------------------
>Añado un campo 'num' porque puede haber varios registros con la
>misma fecha.
>Asumiendo que:
> - la combinación (fecha,num) es única
> - que la tabla solo tiene una cuenta
>
> - debe y haber no pueden tener nulos
>
>select a.fecha, a.num, a.concepto, sum(b.debe - b.haber) as saldo
> from cuenta a inner join cuenta b
> on a.fecha > b.fecha or (a.fecha = b.fecha and a.id >=
>b.id)
>group by a.fecha, a.num, a.concepto
-------------------------------------------------------------------
>(al final lo de 'id' fue una equivocación y tiene que ser 'num')
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.
>
>Por qué crees que he introducido el num? Para forzar un orden total
>y darle sentido al running saldo. Y todo el tiempo asumiendo que la
>fecha es un timestamp del sistema y que lo que se ha introducido es
>definitivo.
>
>
>Después vienes tu y hablas de actualizar fechas, borrar movimientos,
>etc, etc.
>
Hablo de eso porque no se puede programar pensando que las cosas son
estáticas a menos que sea un requisito del diseño. Si llega a serlo pues te
sacaste la lotería pero no creo que eso se dé mucho en sistemas que manejan
saldos.
De la misma forma que no podemos programar pensando que habrá siempre pocos
datos.
>
>Entonces doy aquí un ejemplo de que si eso puede ser, el running
>saldo va a ser un sinsentido. Lo calcule el sgbd, el reporte, la
>aplicación o mi abuela.
>
>Y tu conclusión ahora es que lo que yo propongo es un sinsentido!
>
>Venga ya hombre... vete a tomar el fresco, que te hace falta.
>
Me ire a tomarlo:) pero eso no quita que poner un saldo en un registro de
movimiento sea un sinsentido habiendo otras opciones, incluida tu consulta,
aun con las suposiciones que hiciste.
>
>Concluir, desconfiar que hay confusión es una cosa, pero otra muy
>distinta es que lo que yo propongo es lo que sí es un sinsentido.
>
Es lo que yo creo y lo sigo creyendo, pero hombre... no hay a llorar por
eso.
Vete a tomar fresco que lo necesitas mas que yo parece :)
>
>Por cierto... son muchas las cosas de las que no tengo ni idea,
>pero principiante lo serás tu!
>
Soy principiante y me siento orgulloso de serlo; y cierto que tampoco trato
de opinar y "sabelotodizar" de cosas que desconozco ni tratar de
menospreciar a los demas.
>
>
>Lo dicho.... a tomar el fresco.
>
Despues de vos.
Jose TH
Carlos M. Calvelo
>
> 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. He propuesto mas tarde buscar otras alternativas basándose
en no poder borrar ni cambiar movimientos.
> Me ire a tomarlo:) pero eso no quita que poner un saldo en un registro de
> movimiento sea un sinsentido habiendo otras opciones, incluida tu consulta,
> aun con las suposiciones que hiciste.
>
Qué opciones? Si el calculo no tiene sentido, no tiene sentido.
O tiene mas sentido si se hace muy rápido y en otro lado?
Y es de lo que estas discutiendo. Yo que si con esas condicones
(poder borrar, actualizar) no tiene sentido y tu que si puede
ser mucho mas rápido en otro lado.
Un poco mas de fresco quizás?
Jose Abreu
> >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?
>
Habra que buscar un diccionario.
>
>
>Dónde dije yo eso?
>Estoy empezando a dudar si sabes leer porque no dejas de atribuirme
>cosas que no he escrito.
>
Yo no se leer?! Esa ofensa gratuita .... pues analfabeto seras tu. Por lo
menos escribes muy mal porque despues niegas lo que escribes y tampoco
entiendes bien lo que lees.
Jose Abreu
>Por cierto... son muchas las cosas de las que no tengo ni idea,
>pero principiante lo serás tu!
>
Pues aqui quien mas parecio ser un principiante fuiste tu. y no creo que el
principiante sea tan principiante puesto que sin tener que ofender ni
acusarte de analfabeto, terminó dandote clase.
Alfredo Novoa
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
Alfredo Novoa
<c_ja...@hotmail.com> wrote:
>> >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?
Tiene lo de ad hoc lo mismo que cualquier otro cálculo para obtener un
resultado específico. Es igual de ad hoc si se hace en la aplicación
que en el SGBD, por lo que la frase de Abreu no tiene mucho sentido.
>> 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.
Otra vez la falacia del hombre de paja.
Saludos
Alfredo Novoa
<ricardit...@hotmail.coSm> 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
Alfredo Novoa
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
Alfredo Novoa
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
Alfredo Novoa
>Pues aqui quien mas parecio ser un principiante fuiste tu. y no creo que el
>principiante sea tan principiante puesto que sin tener que ofender ni
>acusarte de analfabeto, terminó dandote clase.
Pero lo acusó de sabelotodo y escribió montones de tonterías como que
un saldo no es un dato.
Saludos
Alfredo Novoa
<alfred...@hotmail.com> wrote:
>On Sat, 14 Jul 2007 09:14:22 -0400, "Ricardo Passians"
><ricardit...@hotmail.coSm> 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
Carlos M. Calvelo
Has empezado a escribir tus dos últimos mensages para aportar
algo y en el proceso has olvidado qué era o qué pasó?
Tu obviamente no te enteras.
Anda, anda.. no me hagas reír más..., que me va a dar
dolor de estómago :)
Carlos M. Calvelo
On 17 jul, 03:51, "Jose Abreu" <j...@j.com> wrote:
> > >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?
>
> Habra que buscar un diccionario.
>
Está claro que tienes un concepto muy raro de muchas cosas. :)
>
>
> >Dónde dije yo eso?
> >Estoy empezando a dudar si sabes leer porque no dejas de atribuirme
> >cosas que no he escrito.
>
> Yo no se leer?!
Hombre, técnicamente hablando, sabrás; pero que tienes un problema
interpretando y asumiendo cosas cuando lees ya lo has demostrado
ampliamente.
> ... porque despues niegas lo que escribes ...
>
>
Puede ser, nadie es perfecto.
O tiene que ver esta conclusión con el no saber leer?
O como parece que a ti hay que deletrearte todo:
"el enterder cosas que no están escritas, al leer."
Carlos M. Calvelo
> On Sun, 15 Jul 2007 15:24:35 -0400, "principiante" <nad...@denada.com>
> 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.
Eso es tan obvio, que no merece respuesta.
> >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.
>
Yo no me considero experto en nada y menos en ERP, ...
> 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.
>
... pero efectivamente. He visto y leído cosas sobre el diseño de
algún ERP que horrorizaría a cualquiera con un mínimo de
conocimientos sobre sistemas de información.
Lo del ERP fue 'salirse por las ramas'; totalmente irrelevante.
Saludos,
Carlos
Jose Abreu
> >de introducción en el sistema, es el saldo anterior + el saldo del
> >moviminto que se introduce. Qué tiene eso de ad hoc?
>
> Habra que buscar un diccionario.
>
>Está claro que tienes un concepto muy raro de muchas cosas. :)
>
Buscalo en el diccionario para que te enteres antes de opinar.
>
>
> >Dónde dije yo eso?
> >Estoy empezando a dudar si sabes leer porque no dejas de atribuirme
> >cosas que no he escrito.
>
> Yo no se leer?!
>
>Hombre, técnicamente hablando, sabrás;
>
Entonces no lo escribiste! ves? por eso te digo que vives negando lo que
escribes.
>pero que tienes un problema
>interpretando y asumiendo cosas cuando lees ya lo has demostrado
>ampliamente.
>
> ... porque despues niegas lo que escribes ...
>
>
>Puede ser, nadie es perfecto.
entonces lo admites y pretendes que yo crea que eres serio discutiendo.
>
>O tiene que ver esta conclusión con el no saber leer?
>
debes saber menos que yo por lo menos.
>
>O como parece que a ti hay que deletrearte todo:
>"el enterder cosas que no están escritas, al leer."
>
eres medio chapucero.
Jose Abreu
"Alfredo Novoa" <alfred...@hotmail.com> escribió en el mensaje
news:8j9p939uijea4j3bi...@4ax.com...
Y tu...., seras el marido de Carlos ?
Jose Abreu
"Carlos M. Calvelo" <c_ja...@hotmail.com> escribió en el mensaje
news:1184673175.1...@m37g2000prh.googlegroups.com...
como quieras lo pongas solo demostraste lo que tu mismo dijiste de que la
experiencia no es fundamental porque tienes menos experiencia que un
principiante..
no es por risa sino por verguenza que te dan dolores de estomago!
Jose Abreu
"Alfredo Novoa" <alfred...@hotmail.com> escribió en el mensaje
news:es5p931s1ngnhncs8...@4ax.com...
Jose Abreu
De verdad tu trabajas en sistemas o eres abogado en una oficina publica?
Lo dicho.... no seras el marido de Carlos?
"Alfredo Novoa" <alfred...@hotmail.com> escribió en el mensaje
news:vt6p93h989lsn1jd8...@4ax.com...
Alfredo Novoa
Si quedaba alguna duda sobre si eras imbécil la has disipado.
Jose Abreu
> 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.
Juan Diego Bueno
"Jose Abreu" <j...@j.com> escribió en el mensaje
news:OntFk6G...@TK2MSFTNGP02.phx.gbl...
> 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...
Jose Abreu
> On Sun, 15 Jul 2007 11:06:18 -0700, "Carlos M. Calvelo"
> <c_ja...@hotmail.com> wrote:
>
>>> >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?
>
> Tiene lo de ad hoc lo mismo que cualquier otro cálculo para obtener un
> resultado específico. Es igual de ad hoc si se hace en la aplicación
> que en el SGBD, por lo que la frase de Abreu no tiene mucho sentido.
>
Hombre , que burro eres.
Busca un diccionario de informatica para que te instruyas en informatica,
animal.
>
> Otra vez la falacia del hombre de paja.
>
hombre de paja es lo que tu haces cuando peleas con tu marido.
Alfredo Novoa
>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.
Jose Abreu
>
> Hay sistemas que son asi pero son muy rigidos por ejemplo para pymes.
>
>>
>>>
>>
>> Pues es exactamente asi como se hace en muchos (quizas la mayoria) de los
>> sistemas contables.
>>
>>Vamos, que sí son estúpidos estos sistemas.
>>
>
> pero el termino no va a los sistemas sino a los analistas.
>
>>
yo creo que los estupidos son gente como esos dos que no se molestan por el
performance del servidor mostrando su inexperiencia y hasta para colmo decir
que no es fundamental.
Llegan al colmo de echarle la culpa al optimizador de sql porque no es
bueno, nunca habia visto tanta estupidez.
Esos se ve que no saben lo que es hacer sistemas.
Jose Abreu
> Pero la eficiencia es prácticamente la misma implementandolo de forma
> procedimental en el servidor que en la aplicación.
>
> otras variables.
> Implementarlo de forma procedimental ya es romper una regla, pero está
> justificado por el mal funcionamiento de SQL Server con este tipo de
> consultas!!!!!!.
>
oye loco, cuantos sistemas has hecho tu?
no eres mas que un burro en performance.
eso lo que da es risa.
Jose Abreu
>>Vamos, que sí son estúpidos estos sistemas.
>>
>
> Eso se da igual con las existencias y los costos en sistemas de control de
> existencias de almacen y en general en cualquier sistema donde hay que
> mantener saldos y movimientos de altas y bajas.
> Ponte a pensarlo.
> Yo creo que lo estúpido es no entender las necesidades de los usuarios,
> pero el termino no va a los sistemas sino a los analistas.
>
>>
Insisto en que le has dado clase.
>
> Hablo de eso porque no se puede programar pensando que las cosas son
> estáticas a menos que sea un requisito del diseño. Si llega a serlo pues
> te sacaste la lotería pero no creo que eso se dé mucho en sistemas que
> manejan saldos.
> De la misma forma que no podemos programar pensando que habrá siempre
> pocos datos.
>
no pienso que entiendan eso, eso solo se logra con la experiencia que no
tienen estos estupidos
>>
>>Entonces doy aquí un ejemplo de que si eso puede ser, el running
>>
>>Por cierto... son muchas las cosas de las que no tengo ni idea,
>>pero principiante lo serás tu!
>>
yo creo que los principiantes son otros que han demostrado que ni saben
hacer un reporte y no le interesa el performance del servidor.
Jose Abreu
>>Y tu...., seras el marido de Carlos ?
>
> Si quedaba alguna duda sobre si eras imbécil la has disipado.
>
por lo menos no me gustan los hombres
Jose Abreu
"Alfredo Novoa" <alfred...@hotmail.com> escribió en el mensaje
news:qgep93ts87la3ho6e...@4ax.com...
Jose Abreu
(porque ahora son dos) empiezan insultando.
acciones traen reacciones.
"Juan Diego Bueno" <moon...@quita-esto.gmail.com> escribió en el mensaje
news:11847765...@proxy.tragsatec.es...
Jose Abreu
me duele el estomago igual que tu marido de la risa....
birra de suma en el cliente.... calcular un balance, hacer un reporte?//
pero que imbecil aparte de loca eres!!!
Carlos M. Calvelo
> "el enterder cosas que no están escritas, al leer."
Ui! Perdona! He querido decir "entender".
No vaya a ser que te confundas por eso.
Carlos M. Calvelo
>
> > ... porque despues niegas lo que escribes ...
>
> >Puede ser, nadie es perfecto.
>
> entonces lo admites y pretendes que yo crea que eres serio discutiendo.
>
Definitivamente tienes graves problemas de comprensión.
Juan Diego Bueno
"Jose Abreu" <j...@j.com> escribió en el mensaje
news:OAV1bMHy...@TK2MSFTNGP04.phx.gbl...
> amigo, revise los mensajes antes de opinar para que vea quien o quienes
> (porque ahora son dos) empiezan insultando.
> acciones traen reacciones.
Por de pronto, procura no utilizar el término "amigo" conmigo. Se elegir a
mis amigos, y solo con leerte se que aunque fueras la única persona que
quedaras sobre la tierra, nunca lo serías.
Lo del quien empezó, me recuerda a los niños de la guardería
Y no he visto ningún insulto por parte de nadie, el problema es el de
siempre, tomarse discrepancias como algo personal... Y eso es un problema,
pero por suerte, es solo tuyo :)
Por otra parte.. al margen de experiencias particulares y de cada cual (yo
tengo las mías propias, y en base a esas actúo, pero también leo y veo otros
puntos de vista), procesar un cálculo fuera del sgbd es como llamar a
telepizza y pedir los ingredientes para hacerte tu la pizza en casa por
quitarle trabajo al de la cocina y al chico de la moto con el único
argumento de que tu lo vas a hacer más rápido aún. Si te compensa...
enhorabuena, sino... me ahorro el adjetivo no vaya a ser que alguien se lo
tome como algo personal.
Saludos
principiante
>>>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.
>
Pero no porque tú lo digas. Como aquí estamos para aprender dime basado en
cuál definición formal un balance o un total de ventas diarias es un dato.
Alguna documentación que me puedas dar?
No es ironía. Si me convences con algo formal te lo acepto.
Mi palabra no es palabra de Dios.
Pero por cierto revisa ésto de otro mensaje para que te ilustres mejor de la
idea por si no estás entendiendo lo que dije:
----
"...
> Pues es exactamente asi como se hace en muchos (quizas la mayoria) de los
> sistemas contables.
>
>Vamos, que sí son estúpidos estos sistemas.
>
"No lo creo.
Eso se da igual con las existencias y los costos en sistemas de control de
existencias de almacen y en general en cualquier sistema donde hay que
mantener saldos y movimientos de altas y bajas.
Ponte a pensarlo.
Yo creo que lo estúpido es no entender las necesidades de los usuarios, pero
el termino no va a los sistemas sino a los analistas."
>
>>
>
----
>
>>>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.
>
Lo crees tú?
>
> Y se dice acceder, no accesar.
>
Es cierto y te agradezco la corrección. A veces, por la informalidad,
cometemos errores en la escritura común en estos foros, pero te recomiendo
que no insistas con eso porque te puedo demostrar fácilmente que
(contabilidad aparte) ese tema (la redacción) es el único en el cual no soy
un principiante.
>>>
>>
>>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.
>
No voy a filosofar sobre éso porque he visto otros hilos tuyos donde se
advierte que para ti no existe nada más allá de un SGBD. Tienes una visión
muy limitada por lo cual convencerte de otras cosas será imposible.
Ya muchos lo intentaron y terminaron en lo mismo: buscar cosas más
productivas qué hacer.
>
> La cuestión es: ¿Que hace esa "capa" que no se pueda hacer más
> fácilmente con SQL Server?
>
Te contradices o no has entendido muy poco de lo que escribí.
>
>>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.
>
Si me da eficiencia ante las limitaciones de un servidor y no es tan grave
en cuanto a "romper reglas", en la práctica debe tener mucho sentido lo que
digo e ideas más ideas menos, dicen otros también
Es parecido a lo que ocurre con la normalización.
Sin sentido es que tú no lo entiendas si es que trabajas programando
sistemas con buen performance.
>
>>> 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?
>
Si discutes con un diccionario a mano revisando siempre el significado
preciso de cada término empleado sin ver la idea y el contexto, demuestras
que tienes muy pocas razones sólidas para rebatir lo que estoy diciendo.
Eso sí es hacer trampas en una discusión pretendiendo un formalismo excesivo
para desviar el tema.
No dejas de decepcionarme pues, a pesar de todo, has hecho muy buenas
aportaciones en muchos hilos.
>>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.
>
Porque tú lo digas? Permíteme reírme. Tienes tú algún ERP desarrollado por
ti ? Podrías dejar ver un diagrama del diseño del modelo contable?
Nota: no lo había dicho ni tenía necesidad pero, aparte de informático
todavía principiante, soy CPA (primera profesión).
>
>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.
>
Aquí veo claro que tu misión aquí (ni lo disimulas) parece la de defensor de
Carlos, tenga éste o no razón.
Poner una columna para mantener un saldo en una tabla de transacciones sí
que es una "chapuza" que yo no he visto frecuentemente salvo en estudiantes.
Hasta la consulta que él propuso en principio ( salvo que los planes de
ejecución digan otra cosa), se lo dije, es mucho mejor que esa última
"chapuza" sin sentido. Si Carlos es un experto, deja mucho que desear con
esa propuesta tan poco inteligente.
Y olvidemos la contabilidad. Aplicaría esa chapuza también para un control
de existencias? para balances de cuentas por cobrar? de cuentas por pagar?
en fin.... para dondequiera que te puedan pedir reportes con un "running
balance" en un ERP.
Además con esa generalización del concepto "dato", hasta los totales por
página tendríamos que traerlos del servidor :) me vuelto a reir...
Si todos los totales siempre hay que traerlos calculados desde el servidor,
el 99% de los sistemas de gestión del mercado están equivocados. Y si me
dices, pues "peor para ellos", yo te respondo, pues "peor para ustedes" que
viven en un mundo ideal.
>
> Parece que no le has visto las "tripas" a muchos ERP.
>
Las has visto tú? Dame ejemplos.
>
>>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.
>
"Sabelotodo" es un insulto? Cámbialo por "engreído" entonces y aplícatelo
también a ti ;-).
Eso no es insulto. Si lo creen así, ustedes son extremadamente sensibles.
Es parte del debate igual como tú acusas de decir tonterías o de
desconocimiento.
José TH
principiante
Te degradas bastante con ese vocabulario. No hay que llegar a eso.
Lee mi otro mensaje.
Jose TH
principiante
> (porque ahora son dos) empiezan insultando.
> acciones traen reacciones.
>
Jose tocayo, si bien la ironía de Carlos uno puede interpretarla en casos
como ofensiva y hasta engreída (yo le llamé "sabelotodo"), siempre estuve
en un aire hasta humorístico y nunca las cosas fueron a lo personal como tú
lo estás haciendo principalmente luego de la aparición de Alfredo Novoa en
la discusión.
No dudo que fuese este último quien te llevara a cambiar de línea, este es
todavía más "sabelotodo" :), por sus palabras descalificadoras tan directas
pero creo que eso nunca justifica que te pases de irrespetuoso y a ti a
debería darte verguenza haber descendido a ese nivel.
Tus primeros mensajes se notaban muy juiciosos donde defendías el valor de
la experiencia pero hay que discutir sin llegar a ataques personales.
Creo que tienes mucho más que eso para responder.
Jose TH
Salvador Ramos
Creo que en los años que llevo en este foro, nunca he leído un hilo en el
que se haya llegado a este nivel de "discusión sin sentido". Creo que esto
estará todo el mundo de acuerdo, además mi intención no es intervenir para
que este hilo siga creciendo, simplemente es para pediros que este tipo de
discusiones, si las consideráis necesarias, sería preferible que las
mantuvieseis en privado.
Es una pena que un tema tan interesante como este, que tiene varias
soluciones, en donde lo ideal sería ir explicando las soluciones por las que
ha optado cada uno, y acompañandolas con código y comentarios. Lo cual sería
muy útil e instructivo para cualquiera que lo leyese, independientemente de
su experiencia, ya que es un caso como el que nos encontramos casi todos en
algun momento.
De hecho, estaba intentando hacer un artículo sobre este tema en
colaboración con el amigo Alejandro Mesa, y aunque este largo hilo me ha
desmotivado un poco, espero que pronto lo pueda tener disponible y
compartirlo con todos los lectores del grupo y de mi web. También por si os
interesa os dejo un link bastante interesante de unos de mayores gurús a
nivel mundial sobre este tema:
http://www.sql.co.il/books/insidetsql2005/resources.htm
Alli tenéis el witepaper "OVER clause and Ordered Calculations - Feature
enhancements" Request by Itzik Ben-Gan and Sujata Mehta
Espero que todos sigáis colaborando en este grupo tan interesante de forma
constructiva, y aportando toda vuestra experiencia y conocimientos.
--
Un saludo
Salvador Ramos
---------------------------------------------------
www.helpdna.net (información sobre SQL Server y Microsoft .Net)
www.helpdna.net/acerca_de_salvador_ramos.htm
---------------------------------------------------
Ricardo Passians
>>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.
>
Es cierto a menos que sea por un cursor. Una de las opciones que di es
usando una tabla temporal que puede ser más rapido todavía que hacerlo 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.
>
Marginales sí. Por supuesto.
>
> Implementarlo de forma procedimental ya es romper una regla, pero está
> justificado por el mal funcionamiento de SQL Server con este tipo de
> consultas.
>
>
Claro que sí.
>
>
>>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.
>
>
También la opción de la tabla temporal creo que suple eso.
Parece que estamos más de acuerdo de lo que podría pensar :)
>
> Saludos
Saludos
Ricardo Passians
Ricardo Passians
Alfredo siempre "calienta" los hilos.... es broma, Alfredo :)
Jose,
Es que no tienes educación? son necesarios esos ataques personales?
Es que no tienes mas nada que opinar que recurres a esas bajezas?
Quien sabe si trayendo ese tema lo que haces es ponerte en evidencia.
No seras tu el que tenga "problemitas" de ese tipo?
Hasta para insultar hay que tener clase. Revísate!!
Ricardo Passians
"Jose Abreu" <j...@j.com> wrote in message
news:O5tziNHy...@TK2MSFTNGP05.phx.gbl...
Ricardo Passians
>
> Soy principiante y me siento orgulloso de serlo;
>
Sí.... cómo no???!!!!
Amén de tener razón o no tener, deberías empezar por cambiarte ese alias de
principiante porque de principiante no tienes nada.
Al menos que seas principiante en física cuántica. :)
Saludos,
Ricardo Passians
Ricardo Passians
>
> Jose tocayo, si bien la ironía de Carlos uno puede interpretarla en
> casos como ofensiva y hasta engreída (yo le llamé "sabelotodo"), siempre
> estuve en un aire hasta humorístico y nunca las cosas fueron a lo
> personal como tú lo estás haciendo principalmente luego de la aparición de
> Alfredo Novoa en la discusión.
>
Jeje... a Alfredo siempre le pasan esas cosas:). Yo recuerdo cierta vez
alguna vieja discusión de apaga y vámonos que tuve también con él en otro
foro no recuerdo el tema.. pero comparto lo que dices de que a Jose Abreu se
le fue la mano pero por mucho al recurrir a esas bajezas incalificables, con
lo cual lo poco o mucho que haya aportado se lo llevó el viento.
>
>
> No dudo que fuese este último quien te llevara a cambiar de línea, este es
> todavía más "sabelotodo" :), por sus palabras descalificadoras tan
> directas pero creo que eso nunca justifica que te pases de irrespetuoso y
> a ti a debería darte verguenza haber descendido a ese nivel.
>
> Tus primeros mensajes se notaban muy juiciosos donde defendías el valor de
> la experiencia pero hay que discutir sin llegar a ataques personales.
>
> Creo que tienes mucho más que eso para responder.
>
mmm.. eso estaria por verse.
Saludos
Ricardo Passians
Ricardo Passians
> Creo que en los años que llevo en este foro, nunca he leído un hilo en el
> que se haya llegado a este nivel de "discusión sin sentido". Creo que esto
> estará todo el mundo de acuerdo, además mi intención no es intervenir para
> que este hilo siga creciendo, simplemente es para pediros que este tipo de
> discusiones, si las consideráis necesarias, sería preferible que las
> mantuvieseis en privado.
>
Creo lo mismo
Saludos
Ricardo Passians
Alfredo Novoa
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.
>
>Pero no porque tú lo digas.
Claro que no, por que un saldo es una información y un dato es una
información.
> Como aquí estamos para aprender dime basado en
>cuál definición formal un balance o un total de ventas diarias es un dato.
Que definición formal ni que chorradas. Ya te he puesto la definición
del diccionario que es la que vale. Dato viene del latín "datum" que
significa "dado". Un dato es un hecho dado, una información, y un
saldo es una información.
>Alguna documentación que me puedas dar?
>No es ironía. Si me convences con algo formal te lo acepto.
Parece que tampoco sabes lo que significa la palabra "formal", por que
la usas sin ningún sentido.
La definición que ya he puesto es AUTORITATIVA. El significado de las
palabras es el que dice la Real Academia por que para eso se creó.
>Pero por cierto revisa ésto de otro mensaje para que te ilustres mejor de la
>idea por si no estás entendiendo lo que dije:
>----
>"...
>> Pues es exactamente asi como se hace en muchos (quizas la mayoria) de los
>> sistemas contables.
>>
>>Vamos, que sí son estúpidos estos sistemas.
>>
>
>"No lo creo.
>Eso se da igual con las existencias y los costos en sistemas de control de
>existencias de almacen y en general en cualquier sistema donde hay que
>mantener saldos y movimientos de altas y bajas.
>Ponte a pensarlo.
>Yo creo que lo estúpido es no entender las necesidades de los usuarios, pero
>el termino no va a los sistemas sino a los analistas."
>>
>>>
>>
>----
Completamente irrelevante y desconectado de la afirmación de que un
saldo no es un dato.
>> Entonces forma parte del SGBD.
>
>Lo crees tú?
Lo se yo y cualquiera que tenga unas nociones elementales sobre teoría
de bases de datos.
>> Y se dice acceder, no accesar.
>>
>
>Es cierto y te agradezco la corrección. A veces, por la informalidad,
>cometemos errores en la escritura común en estos foros, pero te recomiendo
>que no insistas con eso porque te puedo demostrar fácilmente que
>(contabilidad aparte) ese tema (la redacción) es el único en el cual no soy
>un principiante.
No entiendo a que viene esto. Has cometido un error común en este
grupo, lo he corregido y se acabó. No quieras ver cosas raras.
>No voy a filosofar sobre éso porque he visto otros hilos tuyos donde se
>advierte que para ti no existe nada más allá de un SGBD.
La falacia del hombre de paja.
>> La cuestión es: ¿Que hace esa "capa" que no se pueda hacer más
>> fácilmente con SQL Server?
>
>Te contradices o no has entendido muy poco de lo que escribí.
No me contradigo, eres tu el que ha demostrado repetidamente no
entender el español escrito.
>Si me da eficiencia ante las limitaciones de un servidor y no es tan grave
>en cuanto a "romper reglas",
Pero es que resulta que no hay ninguna diferencia de velocidad
significativa si se hace con un procedimiento en el servidor. Que es
lo que estoy diciendo todo el rato.
Además tu mismo has dicho que tu misteriosa "capa de datos" también
puede estar en el servidor.
>Es parecido a lo que ocurre con la normalización.
Si, es parecido, la mayoría de la gente tampoco lo entiende por que
confunden el nivel lógico con el nivel físico.
>Sin sentido es que tú no lo entiendas si es que trabajas programando
>sistemas con buen performance.
La palabra performance no está en el diccionario.
>>>> 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?
>
>Si discutes con un diccionario a mano revisando siempre el significado
>preciso de cada término empleado sin ver la idea y el contexto, demuestras
>que tienes muy pocas razones sólidas para rebatir lo que estoy diciendo.
Estás de broma. Los demás solo podemos ver lo que escribes, no lo que
piensas. Si piensas una cosa pero escribes otra lo normal es que
entendamos la otra y no la una, y la culpa es solo tuya.
Un saldo no es un concepto ni orientado a registros ni a conjuntos.
Ninguna de las dos cosas tiene sentido. Pero si puede calcularse
mediante operaciones de conjuntos u operaciones orientadas a
registros.
>>>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.
>>
>
>Porque tú lo digas? Permíteme reírme. Tienes tú algún ERP desarrollado por
>ti ? Podrías dejar ver un diagrama del diseño del modelo contable?
>Nota: no lo había dicho ni tenía necesidad pero, aparte de informático
>todavía principiante, soy CPA (primera profesión).
Aquí si que estamos claramente hablando de cosas distintas, pensaba
que estabas hablando de la "arquitectura" del sistema y no de modelos
contables o de negocio.
En eso te doy toda la razón. Los ERP suelen ser una chapuza
informática, pero los hay que tienen un diseño funcional muy bueno.
>Poner una columna para mantener un saldo en una tabla de transacciones sí
>que es una "chapuza" que yo no he visto frecuentemente salvo en estudiantes.
Estoy de acuerdo y ya he dicho que no me gustaba la idea. Hay formas
mejores de resolver ese dato en el SGBD.
Pero esto si que es diseño orgánico, no funcional. Así es dificil
seguirte.
Lo que no tiene nada de malo es DEFINIR una columna de saldo en una
tabla de transacciones si se hace bien.
>Además con esa generalización del concepto "dato", hasta los totales por
>página tendríamos que traerlos del servidor :) me vuelto a reir...
El concepto de dato no tiene absolutamente nada que ver con donde hay
que calcular las cosas. Es ridículo.
Un total por página si sería lógico calcularlo en el generador de
informes.
En cambio yo puedo querer ver un saldo en cualquier parte, como por
ejemplo en una consola. Si tenemos el saldo en una vista se puede ver
desde cualquier sitio sin ningún esfuerzo.
>Las has visto tú? Dame ejemplos.
Por ejemplo el modelo de base de datos de SAP R/3 es un churro. La
arquitectura de Navision es un disparate. Yo tengo que mantener un
pequeño ERP que está hecho con los pies, etc.
>>>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.
>>
>
>"Sabelotodo" es un insulto? Cámbialo por "engreído" entonces y aplícatelo
>también a ti ;-).
>
>Eso no es insulto. Si lo creen así, ustedes son extremadamente sensibles.
Si son insultos.
>Es parte del debate igual como tú acusas de decir tonterías o de
>desconocimiento.
Eso no es un insulto. A ver si ves la diferencia.
"Eres tonto" es un insulto.
"Lo que has dicho una tontería" no es un insulto.
Saludos
principiante
>> Como aquí estamos para aprender dime basado en
>>cuál definición formal un balance o un total de ventas diarias es un dato.
>
> Que definición formal ni que chorradas.
>
Lo sabía. No tienes ninguna.
>
>Ya te he puesto la definición
> del diccionario que es la que vale.
>
Esa sí es una tontería, porque no siempre el de la RAE aplica tal cual en la
informática.
>Dato viene del latín "datum" que
> significa "dado". Un dato es un hecho dado, una información, y un
> saldo es una información.
>
Yo pensaba que información y dato no era lo mismo. Si me dices que un
balance es información ya es algo más aceptable y quien sabe si empiece a
comprender las "chorradas" que estás diciendo al respecto.
>
>>Alguna documentación que me puedas dar?
>>No es ironía. Si me convences con algo formal te lo acepto.
>
> Parece que tampoco sabes lo que significa la palabra "formal", por que
> la usas sin ningún sentido.
>
Mejor acepta que no puedes dar una definición FORMAL de dato, ni mucho menos
diferenciarlo del término información.
Puras "chorradas" es lo que continúas diciendo.
>
> La definición que ya he puesto es AUTORITATIVA.
>
Me das risa.
>
>El significado de las
> palabras es el que dice la Real Academia por que para eso se creó.
>
Los términos pueden tener significados más específicos y variados según el
área de conocimientos de la cual se trate. Basarse nada más en la RAE es no
saber eso.
>
>>existencias de almacen y en general en cualquier sistema donde hay que
>>mantener saldos y movimientos de altas y bajas.
>>Ponte a pensarlo.
>>Yo creo que lo estúpido es no entender las necesidades de los usuarios,
>>pero
>>el termino no va a los sistemas sino a los analistas."
>>>
>>>>
>>>
>>----
>
> Completamente irrelevante y desconectado de la afirmación de que un
> saldo no es un dato.
>
Lo dije para explicar que si es un dato para contabilidad, lo es para
cualquier caso donde haya un saldo y por inferencia llegaremos hasta que los
totales por página son datos.
>
>>> Entonces forma parte del SGBD.
>>
>>Lo crees tú?
>
>>(contabilidad aparte) ese tema (la redacción) es el único en el cual no
>>soy
>>un principiante.
>
> No entiendo a que viene esto. Has cometido un error común en este
> grupo, lo he corregido y se acabó. No quieras ver cosas raras.
>
Sin embargo lo sigues haciendo. Te diviertes haciéndote el desagradable.
Di a Carlos que te lleve a tomar fresco, sé que a él le agrada.
>
>>No voy a filosofar sobre éso porque he visto otros hilos tuyos donde se
>>advierte que para ti no existe nada más allá de un SGBD.
>
> La falacia del hombre de paja.
>
>
Falacia? No. Realidad.
Aquí lo sigues demostrando y con creces.
>
>
> No me contradigo, eres tu el que ha demostrado repetidamente no
> entender el español escrito.
>
>
Lo entiendo mucho más que tú. Qué te crees que eres?
>
> Pero es que resulta que no hay ninguna diferencia de velocidad
> significativa si se hace con un procedimiento en el servidor. Que es
> lo que estoy diciendo todo el rato.
>
El mismo problema de Carlos. Di eso si hiciste la prueba o al menos
analizaste los planes de ejecución primero antes de opinar.
Lo hiciste? lo dudo.
Ni tú ni Carlos saben absolutamente nada sobre eficiencia en un servidor.
>
>
>
>>Sin sentido es que tú no lo entiendas si es que trabajas programando
>>sistemas con buen performance.
>
> La palabra performance no está en el diccionario.
>
Claro, desviar el tema con eso vuelve a demostrar tu incompetencia para
hablar de performance o rendimiento.
Es el mismo problema de Carlos, irse por las ramas.
>>
>>Si discutes con un diccionario a mano revisando siempre el significado
>>preciso de cada término empleado sin ver la idea y el contexto, demuestras
>>que tienes muy pocas razones sólidas para rebatir lo que estoy diciendo.
>
> Estás de broma. Los demás solo podemos ver lo que escribes, no lo que
> piensas.
>
Sí pero tomar un término para sacarlo de contexto sin ver la idea es ser
extremadamente estricto o extremadamente malicioso en una discusión
interactiva.
Es que acaso te crees perfecto?
>
>Si piensas una cosa pero escribes otra lo normal es que
> entendamos la otra y no la una, y la culpa es solo tuya.
>
No sólo mía, también lo es de los chapuceros maliciosos que aprovechan
cualquier error mínimo de redacción para alejarse del tema central.
>
>>>
>>ti ? Podrías dejar ver un diagrama del diseño del modelo contable?
>>Nota: no lo había dicho ni tenía necesidad pero, aparte de informático
>>todavía principiante, soy CPA (primera profesión).
>
> Aquí si que estamos claramente hablando de cosas distintas, pensaba
> que estabas hablando de la "arquitectura" del sistema y no de modelos
> contables o de negocio.
>
Pues no, perdón Sr. sabelotodo de la RAE, debí decir algo así como el modelo
del diseño de la base de datos del módulo de contabilidad (general ledger)
del ERP.
>>
>>Poner una columna para mantener un saldo en una tabla de transacciones sí
>>que es una "chapuza" que yo no he visto frecuentemente salvo en
>>estudiantes.
>
> Estoy de acuerdo y ya he dicho que no me gustaba la idea. Hay formas
> mejores de resolver ese dato en el SGBD.
>
> Pero esto si que es diseño orgánico, no funcional. Así es dificil
> seguirte.
>
Iré al diccionario de la RAE para entender eso....
>
> Lo que no tiene nada de malo es DEFINIR una columna de saldo en una
> tabla de transacciones si se hace bien.
>
Como no tengo el diccionario a mano, no sé que quisiste decir con definir.
Pero entre tantas otras, la asumo como otra tontería más de las que ya nos
tienes acostumbrados en el foro.
>
>>Además con esa generalización del concepto "dato", hasta los totales por
>>página tendríamos que traerlos del servidor :) me vuelto a reir...
>
> El concepto de dato no tiene absolutamente nada que ver con donde hay
> que calcular las cosas. Es ridículo.
>
No pudiste siquiera dar una definición clara de dato. Eso es lo ridículo.
>
> Un total por página si sería lógico calcularlo en el generador de
> informes.
>
Vaya!!! por fin acordamos en algo. Estás progresando. Pero, "si" lleva
tilde. :)
A ver, y el total del reporte? sigue siendo un "dato" que no debamos
calcularlo en el generador de informes?
>
> En cambio yo puedo querer ver un saldo en cualquier parte, como por
> ejemplo en una consola. Si tenemos el saldo en una vista se puede ver
> desde cualquier sitio sin ningún esfuerzo.
>
Eso es distinto.
Siempre el saldo corte o puntual he dicho que tiene que venir del servidor
sin discusión.
Lo mismo que a Carlos, léanse los mensajes desde el principio del hilo para
que no opinen tantas tonterías de cosas que se han dicho ya mil veces.
Para que te enteres, aqui hablamos de un caso particular que puso otra
persona para mostrar un "running balance", como diría Carlos.
Unos dicen que ese "running balance" debe venir del servidor ya calculado
con un query, otros decimos que basta con traer el balance inicial y
presentar ese "rb" en un reporte, basado en los registros del rango de
fechas que ya se recuperaron desde el servidor. Otros dieron incluso otras
opciones para evitar ese query aún trayendolos calculados (tabla temporal).
Luego vino Carlos y propuso la brillante idea de calcular el balance y
guardarlo en cada registro asumiendo una data estática que nada más vive en
su cabeza.
Dimos la opinión de que esa es la peor manera y ahí el origen de todo el
rollo. Carlos se ofendió y ahí llegaste tú en su defensa, olvidándote de
leer todos los mensajes primero.
Lo tienes más claro ahora?
>
>
> Por ejemplo el modelo de base de datos de SAP R/3 es un churro.
>
Ja ja jajajajajaj... Ya quisiéramos muchos ser dueños de un "churro" como
ése... Me gustaría ver cómo es el ERP que tú has desarrollado. Lo tienes ?
Me pica la curiosidad.
>La
> arquitectura de Navision es un disparate. Yo tengo que mantener un
> pequeño ERP que está hecho con los pies, etc.
>
No todos son buenos. Pero tú debes saber mucho de ERP's, mucho más que
todos, que los criticas de esa manera.
Me sigues dando risa, sabelotodo.
>
>>>
>>
>>"Sabelotodo" es un insulto? Cámbialo por "engreído" entonces y
>>aplícatelo
>>también a ti ;-).
>>
> Si son insultos.
>
>>Es parte del debate igual como tú acusas de decir tonterías o de
>>desconocimiento.
>
> Eso no es un insulto. A ver si ves la diferencia.
>
> "Eres tonto" es un insulto.
>
> "Lo que has dicho una tontería" no es un insulto.
>
A ti que te gustan, cuál es el nombre de la falacia que acabas de decir?
José TH
principiante
>> Soy principiante y me siento orgulloso de serlo;
>>
>
> Sí.... cómo no???!!!!
>
> Amén de tener razón o no tener,
Estás dudando si tengo razón? oye pero si, salvo algunos detalles, he
estado prácticamente defendiendo lo que has escrito.
No deberías dudar si tengo razón.
>
>deberías empezar por cambiarte ese alias de principiante porque de
>principiante no tienes nada.
>
>
Tengo mucho de principiante en muchas cosas y reconozco que poco en otras.
Aunque quizas creo que en verdad lo voy a cambiar porque me ha atraído a
algunos sabelotodos que han tratado de lucirse conmigo subestimando mis
conocimientos.
>
>
> Saludos,
>
José TH
Alfredo Novoa
Hola Ricardo,
On Tue, 17 Jul 2007 12:51:39 -0400, "Ricardo Passians"
<rpassX...@hotYYmail.ZZcom> wrote:
>Parece que estamos más de acuerdo de lo que podría pensar :)
Eso era lo que yo decía :-)
Saludos
Alfredo
Alfredo Novoa
wrote:
>>> Como aquí estamos para aprender dime basado en
>>>cuál definición formal un balance o un total de ventas diarias es un dato.
>>
>> Que definición formal ni que chorradas.
>
>Lo sabía. No tienes ninguna.
Es difícil tener algo que no existe. Pero puedes consultar las
definiciones del estandar internacional ISO/IEC 2382, que son lo más
parecido a una definición formal que existe.
>>Ya te he puesto la definición
>> del diccionario que es la que vale.
>
>Esa sí es una tontería, porque no siempre el de la RAE aplica tal cual en la
>informática.
Pero es que resulta que en este caso si se aplica tal cual a la
informática. Por si no te habías dado cuenta, la palabra "Inform." que
aparece al principio de la definición significa "Informática".
Y como no podía ser de otra forma, la definición de la RAE es
equivalente a la del estandar ISO/IEC 2382 titulado "Information
Technology Vocabulary", por lo que parece que se han leido el estandar
antes de escribir la definición, como tiene que ser.
Te pongo las definiciones ISO 2382 resumidas:
Información: conocimento que en un determinado contexto tiene un
significado particular.
Dato: representación de una información de una manera formal
susceptible de ser comunicada, interpretada o procesada.
>>Dato viene del latín "datum" que
>> significa "dado". Un dato es un hecho dado, una información, y un
>> saldo es una información.
>
>Yo pensaba que información y dato no era lo mismo.
No es exactamente lo mismo. Cuando dispones una información de manera
que pueda tratarse de forma simbólica por una computadora entonces se
le llama dato.
Por el contrario cuando una persona interpreta un dato proporcionado
por un sistema informático entonces obtiene una información.
> Si me dices que un
>balance es información ya es algo más aceptable
Si esa información está represtantada por una computadora, como
evidentemente es el caso entonces es un dato.
Espero que ya te haya quedado claro de una vez. Sino puedes
comprobarlo tu mismo en el documento ISO/IEC 2382.
>>>(contabilidad aparte) ese tema (la redacción) es el único en el cual no
>>>soy
>>>un principiante.
>>
>> No entiendo a que viene esto. Has cometido un error común en este
>> grupo, lo he corregido y se acabó. No quieras ver cosas raras.
>>
>
>Sin embargo lo sigues haciendo. Te diviertes haciéndote el desagradable.
>Di a Carlos que te lleve a tomar fresco, sé que a él le agrada.
Sigo corrigiendo por que sigues cometiendo errores, a pesar de
presumir de no ser un principiante en la redacción.
>
>>
>>>No voy a filosofar sobre éso porque he visto otros hilos tuyos donde se
>>>advierte que para ti no existe nada más allá de un SGBD.
>>
>> La falacia del hombre de paja.
>
>Falacia? No. Realidad.
>Aquí lo sigues demostrando y con creces.
¿Donde he negado la existencia de las aplicaciones y de sus
responsabilidades?
>> Pero es que resulta que no hay ninguna diferencia de velocidad
>> significativa si se hace con un procedimiento en el servidor. Que es
>> lo que estoy diciendo todo el rato.
>>
>
>El mismo problema de Carlos. Di eso si hiciste la prueba o al menos
>analizaste los planes de ejecución primero antes de opinar.
>Lo hiciste? lo dudo.
Ahora si que has metido la pata hasta el fondo. Los procedimientos no
tienen planes de ejecución. No tienes ni idea sobre lo que hablas.
Esto te ha desenmascarado definitivamente.
>Sí pero tomar un término para sacarlo de contexto sin ver la idea es ser
>extremadamente estricto o extremadamente malicioso en una discusión
>interactiva.
Yo no he sacado nada de contexto ni he sido malicioso en absoluto.
Eres tu el que ha sido muy impreciso.
>Es que acaso te crees perfecto?
Nadie es perfecto, pero las personas con un poco de honestidad
intelectual no le echan la culpa a los demás de sus propios errores.
>>>ti ? Podrías dejar ver un diagrama del diseño del modelo contable?
>>>Nota: no lo había dicho ni tenía necesidad pero, aparte de informático
>>>todavía principiante, soy CPA (primera profesión).
>>
>> Aquí si que estamos claramente hablando de cosas distintas, pensaba
>> que estabas hablando de la "arquitectura" del sistema y no de modelos
>> contables o de negocio.
>>
>
>Pues no, perdón Sr. sabelotodo de la RAE, debí decir algo así como el modelo
>del diseño de la base de datos del módulo de contabilidad (general ledger)
>del ERP.
Te expresas tan mal que es muy difícil tener una conversación contigo.
En principio un CPA no tiene por que saber nada sobre diseño de bases
de datos, y los diseños de bases de datos de los ERP suelen estar
bastante o muy mal.
>>>Poner una columna para mantener un saldo en una tabla de transacciones sí
>>>que es una "chapuza" que yo no he visto frecuentemente salvo en
>>>estudiantes.
>>
>> Estoy de acuerdo y ya he dicho que no me gustaba la idea. Hay formas
>> mejores de resolver ese dato en el SGBD.
>>
>> Pero esto si que es diseño orgánico, no funcional. Así es dificil
>> seguirte.
>>
>
>Iré al diccionario de la RAE para entender eso....
Perdona, me olvidaba de que eres principiante y apenas conoces el
vocabulario de la profesión.
Para explicarlo rápido el análisis funcional es sobre QUE hace el
sistema y el orgánico es sobre COMO hace las cosas el sistema.
Funcionalidad vs. Tecnología.
>> Lo que no tiene nada de malo es DEFINIR una columna de saldo en una
>> tabla de transacciones si se hace bien.
>
> Como no tengo el diccionario a mano, no sé que quisiste decir con definir.
Instala el Mozilla Firefox, tiene un enlace directo al diccionario de
la RAE en la barra de arriba. Te vendrá muy bien.
>Vaya!!! por fin acordamos en algo. Estás progresando. Pero, "si" lleva
>tilde. :)
De todas formas no recuerdo haber visto un informe con totales por
página. No tiene mucho sentido.
>A ver, y el total del reporte? sigue siendo un "dato" que no debamos
>calcularlo en el generador de informes?
Si el servidor te lo puede dar calculado de forma eficiente no veo
razón para calcularlo en la aplicación.
Cuando enseño el total de una factura me lo traigo calculado del
servidor, no se me ocurre hacer todos los cálculos en la aplicación.
Además tengo varias aplicaciones que enseñan facturas y se reutilizan
las vistas.
>> En cambio yo puedo querer ver un saldo en cualquier parte, como por
>> ejemplo en una consola. Si tenemos el saldo en una vista se puede ver
>> desde cualquier sitio sin ningún esfuerzo.
>>
>
>Eso es distinto.
>Siempre el saldo corte o puntual he dicho que tiene que venir del servidor
>sin discusión.
Me refiero al saldo de un intervalo de tiempo. De vez en cuando miro
las transacciones de mi cuenta corriente de un período a través de
Internet, y viene una columna con el saldo.
Si el saldo viene calculado del servidor eso le facilita bastante las
cosas al que programa el cliente web.
Puedes poner:
grid.DataSource = dataTable;
Y listo.
Por cierto, no creo que sea nada normal que se puedan borrar o
insertar apuntes desordenados en una cuenta corriente, que es de lo
que trataba la pregunta original.
>Luego vino Carlos y propuso la brillante idea de calcular el balance y
>guardarlo en cada registro asumiendo una data estática que nada más vive en
>su cabeza.
>Dimos la opinión de que esa es la peor manera y ahí el origen de todo el
>rollo. Carlos se ofendió y ahí llegaste tú en su defensa, olvidándote de
>leer todos los mensajes primero.
Eres tú el que no se ha leido los mensajes, o por lo menos no los has
entendido. Yo llegué criticando la propuesta de Carlos, pero por
diferentes razones.
Hace unos meses mi banco se equivocó y mi cuenta corriente tenía
varias docenas de miles de euros de más, pero cuando se dieron cuenta
del error no insertaron el apunte que faltaba con la fecha en la que
debería haberse hecho, sino que lo hicieron con la fecha actual. Así
que tampoco es tan raro lo que decía Carlos por muy CPA o C3PO que
seas :-)
>Ja ja jajajajajaj... Ya quisiéramos muchos ser dueños de un "churro" como
>ése... Me gustaría ver cómo es el ERP que tú has desarrollado. Lo tienes ?
Me cuesta acostumbrarme a tu incapacidad para comprender el español
escrito. He dicho que trabajo manteniendolo, no que lo haya
desarrollado yo.
Mira, está aquí abajo.
>>Yo tengo que mantener un
>> pequeño ERP que está hecho con los pies, etc.
>> "Eres tonto" es un insulto.
>>
>> "Lo que has dicho una tontería" no es un insulto.
>>
>
>A ti que te gustan, cuál es el nombre de la falacia que acabas de decir?
Sinceramente, no veo ninguna falacia.
Saludos
principiante
>>
>>Lo sabía. No tienes ninguna.
>
> Es difícil tener algo que no existe.
>
Ya eso es otra cosa.
>Pero puedes consultar las
> definiciones del estandar internacional ISO/IEC 2382, que son lo más
> parecido a una definición formal que existe.
>
Eso ya tiene mejor sentido.
>>>Ya te he puesto la definición
>>> del diccionario que es la que vale.
>>
>>Esa sí es una tontería, porque no siempre el de la RAE aplica tal cual en
>>la
>>informática.
>
> Pero es que resulta que en este caso si se aplica tal cual a la
> informática.
>
Puede ser.
> Y como no podía ser de otra forma, la definición de la RAE es
> equivalente a la del estandar ISO/IEC 2382 titulado "Information
> Technology Vocabulary", por lo que parece que se han leido el estandar
> antes de escribir la definición, como tiene que ser.
>
> Te pongo las definiciones ISO 2382 resumidas:
>
> Información: conocimento que en un determinado contexto tiene un
> significado particular.
>
Ok
>
> Dato: representación de una información de una manera formal
> susceptible de ser comunicada, interpretada o procesada.
>
Sigue siendo ambigua.
>>>Dato viene del latín "datum" que
>>> significa "dado". Un dato es un hecho dado, una información, y un
>>> saldo es una información.
>>
>>Yo pensaba que información y dato no era lo mismo.
>
> No es exactamente lo mismo. Cuando dispones una información de manera
> que pueda tratarse de forma simbólica por una computadora entonces se
> le llama dato.
>
Ok
>
> Por el contrario cuando una persona interpreta un dato proporcionado
> por un sistema informático entonces obtiene una información.
>
>
>> Si me dices que un
>>balance es información ya es algo más aceptable
>
> Si esa información está represtantada por una computadora, como
> evidentemente es el caso entonces es un dato.
>
Todo es un dato entonces. Es la misma ambiguedad.
> Espero que ya te haya quedado claro de una vez.
>
No realmente. Pero no te esfuerces más, tú tampoco lo tienes claro.
>Sino puedes
> comprobarlo tu mismo en el documento ISO/IEC 2382.
>
De todos modos, gracias por la referencia. Lo chequearé.
>>> grupo, lo he corregido y se acabó. No quieras ver cosas raras.
>>>
>>
>>Sin embargo lo sigues haciendo. Te diviertes haciéndote el desagradable.
>>Di a Carlos que te lleve a tomar fresco, sé que a él le agrada.
>
> Sigo corrigiendo por que sigues cometiendo errores, a pesar de
> presumir de no ser un principiante en la redacción.
>
>>
Es lo único de lo que presumo, pero no lo vivo pregonando. Tú (como todos)
cometes decenas de errores, sin embargo, no ves a nadie que te viva
corrigiendo en un ambiente como éste que todos asumimos como informal.
Quien vive corrigiendo sintaxis o semántica a los demás, tal como tú lo
haces, sí que realmente demuestra una actitud presumida, engreída y que
resulta muy desagradable.
Pero tómalo por el lado amable. Ser autocrítico es una virtud.
>>>
>>>>No voy a filosofar sobre éso porque he visto otros hilos tuyos donde se
>>>>advierte que para ti no existe nada más allá de un SGBD.
>>>
>>> La falacia del hombre de paja.
>>
>>Falacia? No. Realidad.
>>Aquí lo sigues demostrando y con creces.
>
> ¿Donde he negado la existencia de las aplicaciones y de sus
> responsabilidades?
>
Aquí por ejemplo cuando pretendes mostrar, igual que Carlos, que un
generador de informes que no deba manejar siquiera totales aritméticos
simples, ya que todos los "datos" deben venir del servidor.
Pero aún sin este ejemplo, falacia o no, tienes miles de líneas escritas en
cientos de hilos en decenas de grupos tratando temas similares y provocando
reacciones similares.
>
>>>
>>
>>El mismo problema de Carlos. Di eso si hiciste la prueba o al menos
>>analizaste los planes de ejecución primero antes de opinar.
>>Lo hiciste? lo dudo.
>
> Ahora si que has metido la pata hasta el fondo. Los procedimientos no
> tienen planes de ejecución.
>
Léete en los líbros en línea la ayuda sobre "Create Procedure" y busca sobre
la cláusula recompile.
Los procedimientos almacenados sí que tienen y almacenan los planes de
ejecución de las consultas que contienen.
Por tanto lo que has dicho es un tremendo disparate que denota tu
ignorancia.
>
>No tienes ni idea sobre lo que hablas.
>
Quien no la tiene eres tú. No sabes lo que es un procedimiento almacenado ni
mucho menos lo que es un plan de ejecución.
>
> Esto te ha desenmascarado definitivamente.
>
Y tienes la desfachatez de acusarme justamente de lo que adoleces. Eres un
irresponsable tratando de opinar de lo que no tienes ni la remota idea.
>
>
> Yo no he sacado nada de contexto ni he sido malicioso en absoluto.
> Eres tu el que ha sido muy impreciso.
>
>>Es que acaso te crees perfecto?
>
> Nadie es perfecto, pero las personas con un poco de honestidad
> intelectual no le echan la culpa a los demás de sus propios errores.
>
Pareces estarte describiendo.
>>Pues no, perdón Sr. sabelotodo de la RAE, debí decir algo así como el
>>modelo
>>del diseño de la base de datos del módulo de contabilidad (general ledger)
>>del ERP.
>
> Te expresas tan mal que es muy difícil tener una conversación contigo.
>
> En principio un CPA no tiene por que saber nada sobre diseño de bases
> de datos, y los diseños de bases de datos de los ERP suelen estar
> bastante o muy mal.
>
Ok, como digas, pero no has respondido nada.
>>> mejores de resolver ese dato en el SGBD.
>>>
>>> Pero esto si que es diseño orgánico, no funcional. Así es dificil
>>> seguirte.
>>>
>>
>>Iré al diccionario de la RAE para entender eso....
>
> Perdona, me olvidaba de que eres principiante y apenas conoces el
> vocabulario de la profesión.
>
Por supuesto pero de rendimiento de un servidor sé mil veces más que tú a
pesar de ser un principiante.
>
> Para explicarlo rápido el análisis funcional es sobre QUE hace el
> sistema y el orgánico es sobre COMO hace las cosas el sistema.
> Funcionalidad vs. Tecnología.
>
No era tan difícil seguirme entonces.
>
> Instala el Mozilla Firefox, tiene un enlace directo al diccionario de
> la RAE en la barra de arriba. Te vendrá muy bien.
>
>>Vaya!!! por fin acordamos en algo. Estás progresando. Pero, "si" lleva
>>tilde. :)
>
> De todas formas no recuerdo haber visto un informe con totales por
> página. No tiene mucho sentido.
>
>
>
>>A ver, y el total del reporte? sigue siendo un "dato" que no debamos
>>calcularlo en el generador de informes?
>
> Si el servidor te lo puede dar calculado de forma eficiente no veo
> razón para calcularlo en la aplicación.
>
Tú lo has dicho: "dar calculado de forma eficiente". Analiza esa simple
frase y te dará en la cara toda la basura que has estado escribiendo en
varios mensajes justificando razones sin sentido.
En el fondo me estás dando toda la razón, sólo que tu orgullo de persona
engreída no te deja admitirlo.
>
> Cuando enseño el total de una factura me lo traigo calculado del
> servidor,
>
A mi nunca se me ocurriría calcular un total de ningún documento individual
en una aplicación. Eso sería un riesgo innecesario y hasta estúpido.
Pero el total de una lista de facturas digamos de un rango de fechas, por
supuesto que sí. El total de debes y haberes de un rango de movimientos?
por supuesto que también. Un "running balance"? por supuesto que también.
Son cosas muy diferentes y, entre otras, para esas están los generadores de
informes.
>
>no se me ocurre hacer todos los cálculos en la aplicación.
>
No sé quién ha hablado de "todos los cálculos". De nuevo usas la misma
estrategia que usó Carlos, generalizar lo que uno ha dicho para tratar de
restarle valor.
Estamos hablando de casos muy específicos donde la eficiencia pueda verse
muy afectada y el riesgo no sea catastrófico.
>
> Además tengo varias aplicaciones que enseñan facturas y se reutilizan
> las vistas.
>
ok
>>>
>>
>>Eso es distinto.
>>Siempre el saldo corte o puntual he dicho que tiene que venir del servidor
>>sin discusión.
>
> Me refiero al saldo de un intervalo de tiempo. De vez en cuando miro
> las transacciones de mi cuenta corriente de un período a través de
> Internet, y viene una columna con el saldo.
>
De nuevo das risa.. Crees que estás accediendo directamente al servidor?
Acaso no sabes que lo que te envió esa lista de transacciones fue también
UNA APLICACION (conocida como aplicación Web)?
Tanto que te gusta acusar al otro de ignorante y quien lo está demostrando
hasta el cansancio eres tú.
La verdad que me estoy hartando ya.
>
> Si el saldo viene calculado del servidor eso le facilita bastante las
> cosas al que programa el cliente web.
>
Del servidor web claro, pero no del servidor de bases de datos...
>
> Puedes poner:
>
> grid.DataSource = dataTable;
>
Dijiste "cuando miro las transacciones de mi cuenta corriente". Se supone
que estás siendo usuario de la aplicación web en un explorador cualquiera,
no ? Me podrías explicar como harías eso de sacar un dataTable? Los clientes
(customers) de un banco pueden hacer eso? Tienes una confusión mental
sorprendente.
>
> Por cierto, no creo que sea nada normal que se puedan borrar o
> insertar apuntes desordenados en una cuenta corriente, que es de lo
> que trataba la pregunta original.
>
>
De nuevo a lo mismo, vete a leer los mensajes anteriores. Ya he hablado de
eso bastante en los mensajes a Carlos aclarando varios escenarios que yo
conozco bien.
>
>
> Hace unos meses mi banco se equivocó y mi cuenta corriente tenía
> varias docenas de miles de euros de más,
>
Huh!...No creo que sepas contar hasta ahí... :)
> pero cuando se dieron cuenta
> del error no insertaron el apunte que faltaba con la fecha en la que
> debería haberse hecho, sino que lo hicieron con la fecha actual.
>
Eso es una contrapartida y por supuesto que ellos lo hacen así y con esa
rigidez deben siempre manejar los bancos SUS sistemas. Pero son dos caras
de la moneda. Lo has pensado desde el punto de vista de TU sistema
contable, no el del banco, sino el que tú usas para conciliar con el de
ellos. Piensas que las cosas deban ser tan igualmente rígidas?? Crees que
el digitador que pusiste a llevar tu cuenta en libros en tu sistema no pueda
cometer errores que deba poder corregir libremente? Sabes lo que es balance
en libros a diferencia del balance conciliado? Es solo un ejemplo que dudo
lo hayas pensado.
Pero no te vayas muy lejos, piénsalo también para un sistema tan sencillo
como un manejo de stock donde es frecuente un "runnig balance".
Lo mismo, vuelve a leerte los mensajes pues volviste a demostrar no haber
leído o entendido nada de todo lo que hemos escrito.
>
>>Ja ja jajajajajaj... Ya quisiéramos muchos ser dueños de un "churro" como
>>ése... Me gustaría ver cómo es el ERP que tú has desarrollado. Lo tienes
>>?
>
> Me cuesta acostumbrarme a tu incapacidad para comprender el español
> escrito.
Aquí dijiste explícitamente que el modelo de base de datos de SAP R/3 es "un
churro". Hay también que ser adivino respecto a comprender las estupideces
que escribes?
>
>He dicho que trabajo manteniendolo, no que lo haya
> desarrollado yo.
>
Y yo he dicho éso? Es que tampoco sabes leer.
Mira lo que yo dije después que dijiste que SAP es un "churro":
>>Ja ja jajajajajaj... Ya quisiéramos muchos ser dueños de un "churro" como
>>ése... Me gustaría ver cómo es el ERP que tú has desarrollado. Lo tienes
>>?
Yo dije que quisiera ver el ERP que tú has diseñado, ya que si SAP es un
"churro" el tuyo debe ser la maravilla. Y si criticas los diseños de los
ERP's con tanta autoridad es porque mínimo debes tener diseños alternativos
que sí sean buenos, y sobre todo haber implementado alguno. Es de suponer.
O tú perteneces a esa chusma masificada que sólo sirve para criticar por
criticar?
> Mira, está aquí abajo.
>
>>>Yo tengo que mantener un
>>> pequeño ERP que está hecho con los pies, etc.
>
Lo mismo de siempre.
>>
>>A ti que te gustan, cuál es el nombre de la falacia que acabas de decir?
>
> Sinceramente, no veo ninguna falacia.
>
>
José TH
Carlos M. Calvelo
<recortadas las tonterías irrelevantes>
> Ni tú ni Carlos saben absolutamente nada sobre eficiencia en un servidor.
>
Totalmente irrelevante para la pregunta que yo he hecho
y todavía está sin responder. Véase mas abajo
> Es el mismo problema de Carlos, irse por las ramas.
>
Irse por las ramas es :
- sql reporting services sabe sumar,
- de ERP se puede aprender mucho,
- es el número de página en un reporte un dato?,
- tiene este que venir del servidor?
- etc,
- etc,
> >
> > Un total por página si sería lógico calcularlo en el generador de
> > informes.
> >
>
> Vaya!!! por fin acordamos en algo.
Eso ya estaba acordado hace mucho tiempo y eres tu el único que
quiere discutirlo.
>
> >
> > En cambio yo puedo querer ver un saldo en cualquier parte, como por
> > ejemplo en una consola. Si tenemos el saldo en una vista se puede ver
> > desde cualquier sitio sin ningún esfuerzo.
> >
>
> Eso es distinto.
> Siempre el saldo corte o puntual he dicho que tiene que venir del servidor
> sin discusión.
> Lo mismo que a Carlos, léanse los mensajes desde el principio del hilo para
> que no opinen tantas tonterías de cosas que se han dicho ya mil veces.
> Para que te enteres, aqui hablamos de un caso particular que puso otra
> persona para mostrar un "running balance", como diría Carlos.
> Unos dicen que ese "running balance" debe venir del servidor ya calculado
> con un query, otros decimos que basta con traer el balance inicial y
> presentar ese "rb" en un reporte, basado en los registros del rango de
> fechas que ya se recuperaron desde el servidor. Otros dieron incluso otras
> opciones para evitar ese query aún trayendolos calculados (tabla temporal).
> Luego vino Carlos y propuso la brillante idea de calcular el balance y
> guardarlo en cada registro asumiendo una data estática que nada más vive en
> su cabeza.
> Dimos la opinión de que esa es la peor manera y ahí el origen de todo el
> rollo. Carlos se ofendió y ahí llegaste tú en su defensa, olvidándote de
> leer todos los mensajes primero.
> Lo tienes más claro ahora?
>
Para empezar yo no me he ofendido ni con las aportaciones del que
no aportó nada.
Para seguir el que se olvidó de leer fuistes tu, porque... puedes
repetir como tu dices la misma respuesta mil veces, pero sigue
sin ser respuesta a mi pregunta.
El caso es que la confusión sigue estando ahí y que mi pregunta
todavía no ha tenido respuesta.
Y con tanto contable por aquí... es simplemente decepcionante!
Mas de uno tiene problemas de comprensión.
Carlos M. Calvelo
"principiante" wrote:
> >
> > ¿Donde he negado la existencia de las aplicaciones y de sus
> > responsabilidades?
> >
>
> Aquí por ejemplo cuando pretendes mostrar, igual que Carlos, que un
> generador de informes que no deba manejar siquiera totales aritméticos
> simples, ya que todos los "datos" deben venir del servidor.
Nunca he dicho eso. Todo depende de en que contexto tiene
significado un dato. Creía yo que estaba zanjado eso.
>
> No sé quién ha hablado de "todos los cálculos". De nuevo usas la misma
> estrategia que usó Carlos, generalizar lo que uno ha dicho para tratar de
> restarle valor.
De mi estrategia tu todavia no te has enterado...
> Estamos hablando de casos muy específicos donde la eficiencia pueda verse
> muy afectada y el riesgo no sea catastrófico.
.. porque sigues con la eficiencia y mi pregunta, que no tiene
nada que ver con eso, sigue estando ahí sin respuesta.
principiante
Es más hasta te he tomado un poco de afecto después de ver a Alfredo :)
Saludos y no hay problema,
José TH
"Carlos M. Calvelo" <CarlosM...@discussions.microsoft.com> escribió en
el mensaje news:1F61CA11-6594-4E71...@microsoft.com...
Carlos M. Calvelo
"principiante" wrote:
> pero ya contigo había terminado.
anotado
Alfredo Novoa
wrote:
>> Si esa información está represtantada por una computadora, como
>> evidentemente es el caso entonces es un dato.
>
>Todo es un dato entonces. Es la misma ambiguedad.
No es ambigüedad, es un concepto amplio.
>> Espero que ya te haya quedado claro de una vez.
>
>No realmente. Pero no te esfuerces más, tú tampoco lo tienes claro.
Yo lo tengo clarísimo desde el principio. La definición de la RAE es
tan buena como la que más.
Lo que también ha quedado claro como el cristal es que estabas
completa y absolutamente equivocado y no tienes lo que hay que tener
para reconocer un error.
>Es lo único de lo que presumo, pero no lo vivo pregonando. Tú (como todos)
>cometes decenas de errores, sin embargo, no ves a nadie que te viva
>corrigiendo
Pues que me corrijan, por favor.
>> ¿Donde he negado la existencia de las aplicaciones y de sus
>> responsabilidades?
>
>Aquí por ejemplo cuando pretendes mostrar, igual que Carlos, que un
>generador de informes que no deba manejar siquiera totales aritméticos
>simples, ya que todos los "datos" deben venir del servidor.
>Pero aún sin este ejemplo, falacia o no, tienes miles de líneas escritas en
>cientos de hilos en decenas de grupos tratando temas similares y provocando
>reacciones similares.
Lo voy a dejar, por que no tiene sentido discutir con alguien que no
entiende lo que lee. Decir que la gestión datos es responsabilidad del
SGBD no es lo mismo que negar la existencia de las aplicaciones y sus
responsabilidades como la presentación y la comunicación con los
usuarios.
>>>El mismo problema de Carlos. Di eso si hiciste la prueba o al menos
>>>analizaste los planes de ejecución primero antes de opinar.
>>>Lo hiciste? lo dudo.
>>
>> Ahora si que has metido la pata hasta el fondo. Los procedimientos no
>> tienen planes de ejecución.
>>
>
>Léete en los líbros en línea la ayuda sobre "Create Procedure" y busca sobre
>la cláusula recompile.
>Los procedimientos almacenados sí que tienen y almacenan los planes de
>ejecución de las consultas que contienen.
Lo que has escrito es una demostración de que no te estás enterando de
absolutamente nada.
Voy a intentar explicártelo aunque no creo que lo pilles.
SQL Server genera un plan muy ineficiente para las consultas del tipo
"running total".
Una de las soluciones es reemplazar la consulta por un procedimiento
almacenado.
Un procedimiento y un plan de ejecución son esencialmente la misma
cosa. La diferencia es que se suele llamar plan a un procedimiento
creado automáticamente por el SGBD.
La idea consiste en que si el optimizador genera un procedimiento
ineficiente entonces nos lo saltamos (el optimizador) y lo escribimos
nosotros (el procedimiento). El procedimiento hará lo que nosotros
hayamos especificado y su velocidad dependerá de como lo programemos.
Por lo tanto tu pregunta no tiene ningún sentido y muestra que no te
estás enterando de nada. ¿De que narices de planes de ejecución
estabas hablando?
>>>Pues no, perdón Sr. sabelotodo de la RAE, debí decir algo así como el
>>>modelo
>>>del diseño de la base de datos del módulo de contabilidad (general ledger)
>>>del ERP.
>>
>> Te expresas tan mal que es muy difícil tener una conversación contigo.
>>
>> En principio un CPA no tiene por que saber nada sobre diseño de bases
>> de datos, y los diseños de bases de datos de los ERP suelen estar
>> bastante o muy mal.
>>
>
>Ok, como digas, pero no has respondido nada.
No has preguntado nada.
>> Para explicarlo rápido el análisis funcional es sobre QUE hace el
>> sistema y el orgánico es sobre COMO hace las cosas el sistema.
>> Funcionalidad vs. Tecnología.
>>
>
>No era tan difícil seguirme entonces.
Sigues sin enterarte de nada, eras tú el que no me seguía y por eso te
estaba explicando esos dos términos.
>Tú lo has dicho: "dar calculado de forma eficiente". Analiza esa simple
>frase y te dará en la cara toda la basura que has estado escribiendo en
>varios mensajes justificando razones sin sentido.
>En el fondo me estás dando toda la razón, sólo que tu orgullo de persona
>engreída no te deja admitirlo.
Lo que llevo todo el rato diciendo es que es perfectamente posible
calcular una columna de saldo de una cuenta corriente con SQL de forma
eficiente y por ejemplo Ricardo me ha dado la razón en eso.
Tus problemas de comprensión son realmente graves.
>> Cuando enseño el total de una factura me lo traigo calculado del
>> servidor,
>
>A mi nunca se me ocurriría calcular un total de ningún documento individual
>en una aplicación. Eso sería un riesgo innecesario y hasta estúpido.
>Pero el total de una lista de facturas digamos de un rango de fechas, por
>supuesto que sí.
¿Y que diferencia hay entre calcular el total de una lista de facturas
y el total de una lista de líneas de factura?
Es esencialmente lo mismo y se usan exactamente los mismos operadores
algebraicos.
>> Me refiero al saldo de un intervalo de tiempo. De vez en cuando miro
>> las transacciones de mi cuenta corriente de un período a través de
>> Internet, y viene una columna con el saldo.
>
>De nuevo das risa.. Crees que estás accediendo directamente al servidor?
>Acaso no sabes que lo que te envió esa lista de transacciones fue también
>UNA APLICACION (conocida como aplicación Web)?
>Tanto que te gusta acusar al otro de ignorante y quien lo está demostrando
>hasta el cansancio eres tú.
Te digo simplemente que miro mi cuenta corriente y me sales con esas
estupideces. A eso ya ni se le puede llamar falacia, son puras
babosadas.
>> Si el saldo viene calculado del servidor eso le facilita bastante las
>> cosas al que programa el cliente web.
>>
>
>Del servidor web claro, pero no del servidor de bases de datos...
>>
>
>> Puedes poner:
>>
>> grid.DataSource = dataTable;
>>
>
>Dijiste "cuando miro las transacciones de mi cuenta corriente". Se supone
>que estás siendo usuario de la aplicación web en un explorador cualquiera,
>no ?
No imbécil, no. Si supieses leer verías que después cambio de tema y
estoy hablando del programador de la aplicación Web.
>> Por cierto, no creo que sea nada normal que se puedan borrar o
>> insertar apuntes desordenados en una cuenta corriente, que es de lo
>> que trataba la pregunta original.
>
>De nuevo a lo mismo, vete a leer los mensajes anteriores. Ya he hablado de
>eso bastante en los mensajes a Carlos aclarando varios escenarios que yo
>conozco bien.
Pues parece que el de las cuentas corrientes no lo conoces, y este
hilo trata de eso.
>Eso es una contrapartida y por supuesto que ellos lo hacen así y con esa
>rigidez deben siempre manejar los bancos SUS sistemas.
Pues eso.
>>>Ja ja jajajajajaj... Ya quisiéramos muchos ser dueños de un "churro" como
>>>ése... Me gustaría ver cómo es el ERP que tú has desarrollado. Lo tienes
>>>?
>>
>> Me cuesta acostumbrarme a tu incapacidad para comprender el español
>> escrito.
>
>Aquí dijiste explícitamente que el modelo de base de datos de SAP R/3 es "un
>churro". Hay también que ser adivino respecto a comprender las estupideces
>que escribes?
>
>>
>>He dicho que trabajo manteniendolo, no que lo haya
>> desarrollado yo.
>>
>
>Y yo he dicho éso? Es que tampoco sabes leer.
Ya no me quedan dudas, eres subnormal profundo.
Te repito tu frase:
>>>ése... Me gustaría ver cómo es el ERP que tú has desarrollado.
Te añado al filtro anti-idiotas, que ya he tardado demasiado en
hacerlo.
Háztela mirar, por que te funciona muy mal.
principiante
> Lo que también ha quedado claro como el cristal es que estabas
> completa y absolutamente equivocado y no tienes lo que hay que tener
> para reconocer un error.
>
Me sigues dando risa... ya hasta pena diría.
>>Es lo único de lo que presumo, pero no lo vivo pregonando. Tú (como todos)
>>cometes decenas de errores, sin embargo, no ves a nadie que te viva
>>corrigiendo
>
> Pues que me corrijan, por favor.
>
A pocos les gusta perder tiempo en tonterías y formalismos innecesarios,
sólo a gente que no tiene mucho qué hacer como vos.
>
>>> ¿Donde he negado la existencia de las aplicaciones y de sus
>>> responsabilidades?
>>
>>Aquí por ejemplo cuando pretendes mostrar, igual que Carlos, que un
>>generador de informes que no deba manejar siquiera totales aritméticos
>>simples, ya que todos los "datos" deben venir del servidor.
>>Pero aún sin este ejemplo, falacia o no, tienes miles de líneas escritas
>>en
>>cientos de hilos en decenas de grupos tratando temas similares y
>>provocando
>>reacciones similares.
>
> Lo voy a dejar, por que no tiene sentido discutir con alguien que no
> entiende lo que lee.
>
Te sigues describiendo.. Por qué será?
>
>Decir que la gestión datos es responsabilidad del
> SGBD no es lo mismo que negar la existencia de las aplicaciones y sus
> responsabilidades como la presentación y la comunicación con los
> usuarios.
>
Dicho así hasta parece que tienes razón.. Pero no, lo que ocurre es que me
sigues dando la razón a mi para no seguir quedando más desacreditado.
>
>>>
>>> Ahora si que has metido la pata hasta el fondo. Los procedimientos no
>>> tienen planes de ejecución.
>>>
>>
>>Léete en los líbros en línea la ayuda sobre "Create Procedure" y busca
>>sobre
>>la cláusula recompile.
>>Los procedimientos almacenados sí que tienen y almacenan los planes de
>>ejecución de las consultas que contienen.
>
> Lo que has escrito es una demostración de que no te estás enterando de
> absolutamente nada.
>
Es difícil rebatir algo tan obvio. A ver, pues....
>
> Voy a intentar explicártelo aunque no creo que lo pilles.
>
Si no lo creyeras no lo hicieras, más bien creo que me estás admirando ante
tu clara derrota en esta discusión.
>
> SQL Server genera un plan muy ineficiente para las consultas del tipo
> "running total".
>
Ok.
>
> Una de las soluciones es reemplazar la consulta por un procedimiento
> almacenado.
>
Ok.
>
> Un procedimiento y un plan de ejecución son esencialmente la misma
> cosa.
>
No será en SQL server ?
Te falta mucho por estudiar o realmente no has trabajado nunca con SQL
server.
Mira lo que hago por ti, te doy links para que te enteres. Sé que todavía
se puede hacer algo por ti. Hay gente que no es culpable de su falta de
instrucción.
http://grimpi.blogspot.com/2007/05/entender-plan-de-ejecucion-en-sql.html
http://www.sql-server-performance.com/
>
>La diferencia es que se suele llamar plan a un procedimiento
> creado automáticamente por el SGBD.
>
Otra burrada digna de ti, a las que ya nos tienes acostumbrados en estos
foros.
Hombre, los libros en línea también están en español. Allí te lo explican
muy pero muy claro.
Dátele una chequeadita, si?
También chequea la diferencia entre consulta y procedimiento.
>
> La idea consiste en que si el optimizador genera un procedimiento
> ineficiente entonces nos lo saltamos (el optimizador) y lo escribimos
> nosotros (el procedimiento).
>El procedimiento hará lo que nosotros
> hayamos especificado y su velocidad dependerá de como lo programemos.
>
> Por lo tanto tu pregunta no tiene ningún sentido y muestra que no te
> estás enterando de nada. ¿De que narices de planes de ejecución
> estabas hablando?
>
Yo estoy hablando de los planes que tú mismo citaste cuando, si es que
recuerdas, escribiste: "Los procedimientos no tienen planes de ejecución".
Me podrías decir dónde o quién aparte de ti corrobora esa afirmación ? Lo
dice en algún libro o artículo ?
Lo dice en la ayuda de SQL Server?
No te lo quería repetir, pero me has decepcionado bastante.
>
>>
>>> sistema y el orgánico es sobre COMO hace las cosas el sistema.
>>> Funcionalidad vs. Tecnología.
>>>
>>
>>No era tan difícil seguirme entonces.
>
> Sigues sin enterarte de nada, eras tú el que no me seguía y por eso te
> estaba explicando esos dos términos.
>
Jajajaja.
>
>>varios mensajes justificando razones sin sentido.
>>En el fondo me estás dando toda la razón, sólo que tu orgullo de persona
>>engreída no te deja admitirlo.
>
> Lo que llevo todo el rato diciendo es que es perfectamente posible
> calcular una columna de saldo de una cuenta corriente con SQL de forma
> eficiente y por ejemplo Ricardo me ha dado la razón en eso.
>
>
Pues fui yo quien mencioné las soluciones de Ricardo mucho antes de que tú
entraras a DAÑAR esta discusión que se estuvo llevando siempre con mucha
altura entre profesionales.
Ahora veo que los profesionales estamos de un solo lado.
>
> Tus problemas de comprensión son realmente graves.
>
Te sigues auto-describiendo. Por qué será ?
>
>>> Cuando enseño el total de una factura me lo traigo calculado del
>>> servidor,
>>
>>A mi nunca se me ocurriría calcular un total de ningún documento
>>individual
>>en una aplicación. Eso sería un riesgo innecesario y hasta estúpido.
>>Pero el total de una lista de facturas digamos de un rango de fechas, por
>>supuesto que sí.
>
> ¿Y que diferencia hay entre calcular el total de una lista de facturas
> y el total de una lista de líneas de factura?
>
Pues te explico.. Porque es una convención en sistemas de ese tipo que las
líneas de detalle del documento van a una tabla separada del encabezado. En
éste se guarda el cálculo (redundate sí, desnormalizado también) de la suma
de las líneas (quizás un subtotal) y probablemente haya en el encabezado
otros campos como IVA que se agregan a aquel cálculo para dar un total del
documento y guardarlo en el propio header y dar ese valor como oficial del
documento, el que referenciamos casi en el 100% de los reportes donde no sea
necesario ver ni sumar los detalles. Podríamos agregar quizas un check que
valide la consistencia header-detail.
Pero no sólo para una factura, lo generalizo para cualquier documento
(header-detail) como puedes leer en lo que escribí. Así se acostumbra a
programar sistemas de gestión eficientes (para ni siquiera mencionarte de
nuevo los ERPs donde quedaste muy mal por cierto).
Ahora bien, viendo como discutes, me dirás que cada vez que querramos ver el
total de una factura sumemos sus detalles en una vista que tengamos para
eso. Eso no es malo pero, si es importante el rendimiento del servidor
(distinto al mundo ficticio en que tú "programas), lo podemos evitar.
>
> Es esencialmente lo mismo y se usan exactamente los mismos operadores
> algebraicos.
>
Claro, en el mundo ideal del algebra relacional no existe la
desnormalización para favorecer la eficiencia.
>>>> Me refiero al saldo de un intervalo de tiempo. De vez en cuando miro
>>> las transacciones de mi cuenta corriente de un período a través de
>>> Internet, y viene una columna con el saldo.
>>
>>De nuevo das risa.. Crees que estás accediendo directamente al servidor?
>>Acaso no sabes que lo que te envió esa lista de transacciones fue también
>>UNA APLICACION (conocida como aplicación Web)?
>>Tanto que te gusta acusar al otro de ignorante y quien lo está demostrando
>>hasta el cansancio eres tú.
>
> Te digo simplemente que miro mi cuenta corriente y me sales con esas
> estupideces. A eso ya ni se le puede llamar falacia, son puras
> babosadas.
>
Para usar tus mismos insultos, imbécil, tú escribiste en el contexto del
tópico que estamos debatiendo: "De vez en cuando miro las transacciones de
mi cuenta corriente de un período a través de Internet, y viene una columna
con el saldo." .. y "Si el saldo viene calculado del servidor eso le
facilita bastante las cosas al que programa el cliente web."
Qué sabes tú desde un simple explorador si viene o no viene calculado desde
el servidor? Eres adivino acaso?
No sabes que una aplicación web es también una aplicación ?
Te lo repito porque tu respuesta no fue más que una evasiva porque quedaste
en una ridícula evidencia.
>>Dijiste "cuando miro las transacciones de mi cuenta corriente". Se supone
>>que estás siendo usuario de la aplicación web en un explorador cualquiera,
>>no ?
>
> No imbécil, no.
>
El imbécil y además ridículo y desvergonzado eres tú.
> hilo trata de eso.
>
>>Eso es una contrapartida y por supuesto que ellos lo hacen así y con esa
>>rigidez deben siempre manejar los bancos SUS sistemas.
>
> Pues eso.
>
>>>>Ja ja jajajajajaj... Ya quisiéramos muchos ser dueños de un "churro"
>>>>como
>>>>ése... Me gustaría ver cómo es el ERP que tú has desarrollado. Lo
>>>>tienes
>>>>?
>>>
>>> Me cuesta acostumbrarme a tu incapacidad para comprender el español
>>> escrito.
>>
>>Aquí dijiste explícitamente que el modelo de base de datos de SAP R/3 es
>>"un
>>churro". Hay también que ser adivino respecto a comprender las
>>estupideces
>>que escribes?
>>
>>>
>>>He dicho que trabajo manteniendolo, no que lo haya
>>> desarrollado yo.
>>>
>>
>>Y yo he dicho éso? Es que tampoco sabes leer.
>
> Ya no me quedan dudas, eres subnormal profundo.
>
Claro, a eso llegas cuando no tienes respuesta y haces el ridículo.
Más subnormal e ignorante eres tú mil veces. Aquí lo has vuelto a demostrar
igual que en miles de mensajes que pululan la web.
>
>
>>>>ése... Me gustaría ver cómo es el ERP que tú has desarrollado.
>
> Te añado al filtro anti-idiotas, que ya he tardado demasiado en
> hacerlo.
>
Enséñame por qué es un churro el diseño del SAP ? no diste ni una sola razón
concreta. Lo dicho que eres parte de la "chusma masificada" que sólo sabe
criticar por criticar sin sustentar absolutamente nada.
En google se ve que siempre que pierdes una discusión la terminas igual con
el filtro anti-alfredos, excusas, anti-idiotas :).
Yo puedo seguir rebatiendo todas las cosas que dices porque a mi me sobran
las ideas sólidas para hacerlo. Tú te entregas y me metes a un filtro
anti-idiotas donde muchos te tienen desde hace tiempo, por si no sabías.
Ahí demuestras cómo perdiste un debate y huyes como un cobarde, ridículo e
irresponsable.
Aquí el único que ha dejado sentado ser un idiota que no sabe absolutamente
nada sobre performance eres tú.
Tardaré meses en dejar de reírme de muchas de tus "teorías" sobre los planes
de ejecución, procedimientos, el SAP, aplicaciones web, servidor, etc. etc.
ete
Lo bueno es que esto queda en la web registrado para que cada vez que me
sienta estresado pueda releerlas y volver a distenderme entre risas y
risas... jajajajajaj.
José TH
El principiante
principiante
> Pues te explico.. Porque es una convención en sistemas de ese tipo que las
> líneas de detalle del documento van a una tabla separada del encabezado.
Corrección. Aclaro que lo que es convención no es que el detalle y el header
sean entidades separadas (lo son de por sí), si no que se conviene en
guardar el total de los valores de las líneas de detalle en un campo de la
tabla de encabezado.
Esto lo aclaro por si a alguien normal, no sub-normal, le puede interesar
:)
Saludos
José TH
Jose Abreu
"Juan Diego Bueno" <moondance....@ya.com> escribió en el mensaje
news:OqUtXmHy...@TK2MSFTNGP02.phx.gbl...
Jose Abreu
>> amigo, revise los mensajes antes de opinar para que vea quien o quienes
>> (porque ahora son dos) empiezan insultando.
>> acciones traen reacciones.
>>
>
> Jose tocayo, si bien la ironía de Carlos uno puede interpretarla en
> casos como ofensiva y hasta engreída (yo le llamé "sabelotodo"), siempre
> estuve en un aire hasta humorístico y nunca las cosas fueron a lo
> personal como tú lo estás haciendo principalmente luego de la aparición de
> Alfredo Novoa en la discusión.
> No dudo que fuese este último quien te llevara a cambiar de línea, este es
> todavía más "sabelotodo" :), por sus palabras descalificadoras tan
> directas pero creo que eso nunca justifica que te pases de irrespetuoso y
> a ti a debería darte verguenza haber descendido a ese nivel.
>
si sigues discutiendo con ese homosexual terminaras en lo mismo que yo
porque fijate el tipo de irrespeto que el emplea y yo solo me di cuenta
rapido de que calaña de gente se trataba.
Jose Abreu
> Jose,
> Es que no tienes educación? son necesarios esos ataques personales?
> Es que no tienes mas nada que opinar que recurres a esas bajezas?
>
es que ustedes solo ven las bajezas de un solo lado porque algunos con
palabritas de diccionario te ofenden mas que con palabras vulgares
>
> Quien sabe si trayendo ese tema lo que haces es ponerte en evidencia.
> No seras tu el que tenga "problemitas" de ese tipo?
>
no, a mi no me gustan los hombres
Jose Abreu
>>
>> Un procedimiento y un plan de ejecución son esencialmente la misma
>> cosa.
>>
>
> No será en SQL server ?
> Te falta mucho por estudiar o realmente no has trabajado nunca con SQL
> server.
>
si despues de ver esa afirmacion tan pobre sobre plan y procedimiento tu
sigues discutiendo con ese anormal el que no se respeta eres tu.
Creo que le has dado demasiada importancia.
Juan Diego Bueno
Creo que te pega mucho más ese grupo.
No voy a entrar en tu dinámica de insultos, yo no te he faltado al respeto
Tú mismo te dejas en evidencia y además lloras porque sólo te lo
reprochan/reprochamos a ti...
"Jose Abreu" <j...@j.com> escribió en el mensaje
news:uUetLTfy...@TK2MSFTNGP03.phx.gbl...
Carlos M. Calvelo
> Tardaré meses en dejar de reírme de muchas de tus "teorías" sobre los planes
> de ejecución, procedimientos, el SAP, aplicaciones web, servidor, etc. etc.
> ete
Al ritmo que llevas, puede que tardes años en encontrar
razones para dejar de reírte.
>
> Lo bueno es que esto queda en la web registrado para que cada vez que me
> sienta estresado pueda releerlas y volver a distenderme entre risas y
> risas... jajajajajaj.
>
Claro! Eso es lo bueno. Ves como lo entiendes.
Quedará registrado como 'hecho histórico'. Y si algún día, uno se
dá cuenta de las tonterías escritas, no debe ser posible borrar
mensages, ni actulizar el autor, la fecha, el asunto o el contenido.
Se tendrá que enviar una reacción 'de corrección' para que todos
podamos ver en qué orden y con qué contenido se han ido
introduciendo 'las transacciones'. Se verá así como se va
acumulando el valor de estas (contenido con valor - tonterías)
en orden cronológico; vamos... el 'running' saldo.
Está bien el sistema este. Seguro que no fue pensado por
contables a los que le gusta hacer chanchullos.
msnews.microsoft.com
si me permiten, quisiera opinar que, lejos de pelearnos enre nosotros, sería
muy interesante que cada uno pueda sacar una conclusión que lo ayude a
seguir resolviendo los problemas que se plantean a diario en este facinante
mundo de las bases de datos y las aplicaciones
gracias, muchas gracias a todos por involucrarse tanto, he aprendido mucho
con esta discusión
es indudable que saben de verdad
saludos
Pablo
"Carlos M. Calvelo" <CarlosM...@discussions.microsoft.com> escribió en
el mensaje news:750EACB9-A96D-484B...@microsoft.com...
Claudio Bonino
> Hola Pablo,
> On 6 jul, 21:18, "msnews.microsoft.com" <maurizi.pa...@flair.com.ar>
> wrote:
> > 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 ?
> >
> Añado un campo 'num' porque puede haber varios registros con la
> misma fecha.
> Asumiendo que:
> - la combinación (fecha,num) es única
> - que la tabla solo tiene una cuenta
> - debe y haber no pueden tener nulos
> select a.fecha, a.num, a.concepto, sum(b.debe - b.haber) as saldo
> from cuenta a inner join cuenta b
> on a.fecha > b.fecha or (a.fecha = b.fecha and a.id >= b.id)
> group by a.fecha, a.num, a.concepto
> Saludos,
> Carlos
Hola Carlos,
Querría ver si mes ayudas para modificar tu select asumiendo que la tabla tiene mas de una cuenta y que pueda acumular el saldo sólo de una cuenta específica
Saludos
cpb.sos
En sql server existen campos calculados.
Simplemente tienes que colocar la fórmula
Espero haberte ayudado.
Alfredo Valverde
> 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 ?
> Pablo
981556538