Factura, líneas de facturas, artículo

Hola Daniel,

On Fri, 24 Nov 2006 10:40:17 -0300, "Daniel Ruzo"
wrote:

Un último esfuerzo para tratar de entendernos.

La empresa ha decidido que los clientes que hayan efectuado compras por más
de $10.000 en el mes tendrán una bonificación del 1% que se hará efectiva
mediante una nota de crédito el primer día del mes siguiente.

¿Cómo implementarías esto EXCLUSIVAMENTE en el SGBD?

Aquí hay una mezcla de lógica de datos y de lógica de presentación.

Para obtener la relación de bonificaciones puedes usar una vista o una
consulta muy sencilla. Para generar y enviar las notas de crédito
(lógica de presentación) debes de usar una aplicación, que podría ser
un stored procedure o una aplicación externa (por ejemplo una
aplicación Windows Forms).

Si quieres que la generación y envío de notas de crédito sea
automática sería mejor programarla como un stored procedure que se
lanzase el primer día de cada mes.

Un SGBD no es más que un servidor de aplicaciones especializado que
podemos extender con nuevas aplicaciones. Un stored procedure no es
otra cosa que una aplicación.


Saludos

Alfredo Novoa schreef:

Hola Daniel,

On Fri, 24 Nov 2006 10:40:17 -0300, "Daniel Ruzo"
wrote:

>Un último esfuerzo para tratar de entendernos.
>
>La empresa ha decidido que los clientes que hayan efectuado compras por más
>de $10.000 en el mes tendrán una bonificación del 1% que se hará efectiva
>mediante una nota de crédito el primer día del mes siguiente.
>
>¿Cómo implementarías esto EXCLUSIVAMENTE en el SGBD?

Aquí hay una mezcla de lógica de datos y de lógica de presentación.

Para obtener la relación de bonificaciones puedes usar una vista o una
consulta muy sencilla. Para generar y enviar las notas de crédito
(lógica de presentación) debes de usar una aplicación, que podría ser
un stored procedure o una aplicación externa (por ejemplo una
aplicación Windows Forms).

Si quieres que la generación y envío de notas de crédito sea
automática sería mejor programarla como un stored procedure que se
lanzase el primer día de cada mes.

Un SGBD no es más que un servidor de aplicaciones especializado que
podemos extender con nuevas aplicaciones. Un stored procedure no es
otra cosa que una aplicación.

Hola Alfredo,

Si... todo eso está muy bien, pero es tan sencillo... Sobre todo
si lo deletreas. La cosa va a parecer tan sencilla que ya solo por eso
no va a ser creíble. Si no hay clases ni colecciones de objetos por
los
que se pueda navegar, dándote asi la impresión de estas solucionando
problemas nunca vistos, qué nos queda entonces para masturbarnos
mentalmente y sentirnos genios de verdad? eh?
Un patrón de diseño que divida el probrema en muchos problemas
pequeñitos, vamos... algo infinitesimal, pudiendo asi acumular
resultados,
en un un estado de éxtasis, hacia un solución final, el climax, y
después poder dominar toda esa complejidad... eso si que excita! ;-)
Vamos.. que para qué he estado yo estudidando el UML si la solución
es un simple select en SQL?
Y ademas el mantenimiento de tal solución, sobre todo en el caso de
múltiples aplicaciones, va a resultar tan barato que uno se pregunta
que
es lo que vamos a comer mañana. Nos estás tomando el pelo o qué? :-)

Saludos,
Carlos

Alfredo Novoa schreef:

Hola Daniel,

On Fri, 24 Nov 2006 10:40:17 -0300, "Daniel Ruzo"
wrote:

>Un último esfuerzo para tratar de entendernos.
>
>La empresa ha decidido que los clientes que hayan efectuado compras por más
>de $10.000 en el mes tendrán una bonificación del 1% que se hará efectiva
>mediante una nota de crédito el primer día del mes siguiente.
>
>¿Cómo implementarías esto EXCLUSIVAMENTE en el SGBD?

Aquí hay una mezcla de lógica de datos y de lógica de presentación.

Para obtener la relación de bonificaciones puedes usar una vista o una
consulta muy sencilla. Para generar y enviar las notas de crédito
(lógica de presentación) debes de usar una aplicación, que podría ser
un stored procedure o una aplicación externa (por ejemplo una
aplicación Windows Forms).

Si quieres que la generación y envío de notas de crédito sea
automática sería mejor programarla como un stored procedure que se
lanzase el primer día de cada mes.

Un SGBD no es más que un servidor de aplicaciones especializado que
podemos extender con nuevas aplicaciones. Un stored procedure no es
otra cosa que una aplicación.


Saludos

Hola Alfredo,

Si... todo eso está muy bien, pero es tan sencillo... Sobre todo
si lo deletreas. La cosa va a parecer tan sencilla que ya solo por eso
no va a ser creíble. Si no hay clases ni colecciones de objetos por
los que se pueda navegar, dándote asi la impresión de estar
solucionando problemas nunca vistos, qué nos queda entonces
para masturbarnos mentalmente y sentirnos genios de verdad? eh?
Un patrón de diseño que divida el problema en muchos problemas
pequeñitos, vamos... algo infinitesimal, pudiendo asi acumular
resultados, en un estado de éxtasis, hacia una solución final, el
climax, y después poder dominar toda esa complejidad... eso si
que excita! ;-)
Vamos.. que para qué he estado yo estudidando el UML si la solución
es un simple select en SQL?
Y además el mantenimiento de tal solución, sobre todo en el caso de
múltiples aplicaciones, va a resultar tan barato que uno se pregunta
que es lo que vamos a comer mañana. Nos estás tomando el pelo o qué?
:-)

Saludos,
Carlos

Alfredo:

Creo que al final nos entendemos...

Aquí hay una mezcla de lógica de datos y de lógica de presentación.

Y la lógica de presentanción debe imprescindiblemente manejar datos...

Para obtener la relación de bonificaciones puedes usar una vista o una
consulta muy sencilla. Para generar y enviar las notas de crédito
(lógica de presentación) debes de usar una aplicación, que podría ser
un stored procedure o una aplicación externa (por ejemplo una
aplicación Windows Forms).

Prefiero tener un objeto llamado "cliente" (que derivaría de un objeto padre
"cuenta") con un método "calcularBonificaciones" que recibiría el resultado
de esa vista o consulta sencilla. El objeto tendría también otro método
"emitirCredito". Y mi objeto "cuenta" tendría un método
"registrarCredito"...

Si quieres que la generación y envío de notas de crédito sea
automática sería mejor programarla como un stored procedure que se
lanzase el primer día de cada mes.

Un SGBD no es más que un servidor de aplicaciones especializado que
podemos extender con nuevas aplicaciones. Un stored procedure no es
otra cosa que una aplicación.

El inconveniente que tiene tu propuesta arquitectura es que si quiero
instalar mi aplicación en otro SGBD tendría que reescribir toda mi
aplicación, porque la forma de programar los stored procedures es una de las
mayores diferencias que encuentras de un SGBD a otro. Y eso sin contar que
algunos SGBD, como MySQL previo a la versión 5, no soportan stored
procedures ni vistas en el motor.

Sería bueno que aceptáramos que existen múltiples problemas y múltiples
soluciones. Y que en este caso, la elección de una solución como la más
adecuada no depende de querer aumentar los costos sino de la portabilidad
que se quiera alcanzar para la aplicación.

¡Saludos!

*****************************************************
Daniel Ruzo
Miembro del GCU (Grupo Clarion Uruguay)
*****************************************************